Hacker News Reader

Comment by meddlepal | Hacker News Reader

I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?

View on HN

HTTP/2 works well, so adoption speed isn't that important.

On the other hand, HTTP/3 is way, way faster. So there are strong incentives for big players to adopt it as fast as possible :)

Disagree. There's more incentive to move considering the advantages it offers. If anything it feels like people were reluctant to adopt http2 and http3 is a bigger leap that we'll all want to move forward with.

The challenge for http/3 will be middleboxes not endpoints. Put another way: it won't be hard to break 50% of traffic on http/3 but you will still be running 2 10 years from now if you want to reach the last 10% of users.

Middleboxes will only see UDP, no? From their perspective nothing has changed? Isn’t that the whole idea?

How many middleboxes block all UDP?

QUIC forcing these boxes out of the network is a feature not a bug.

The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?

Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.

Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.

Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.

There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.

My firewall doesn't do NAT yet is still stateful for IPv6.

Also, most firewalls on end-point devices (think built-in to the OS) are stateful firewalls.

If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet.

The load balancer will route any ongoing sessions with the session id, and not the ip address.

Absolutely, but the original commenter was stating that it would allow either endpoint to their their IP easily (and thus making load balancing easier). I was disputing that.

Ah... apologies for my confusion. Thanks for the clarification.

I think it's more about the client changing their IP, i.e. moving wifi networks or from wifi to mobile. Not so much the server changing.

Client changing their IP address is fine, the comment I was replying to was stating that it would allow both sides to change their IP at will (and allow for better load balancing). I was disputing that.

You can solve that with STUN which is how WebRTC does it. Each end sends a STUN packet to get the NAT statefullness going.

Granted, it requires transferring of ICE connection candidates out of band (via the horrors of SDP)

While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which assigns each connection (5-tuple) to a thread. If QUIC were to be more widely used, the association of the connection would have to be linked to the connection identifier in QUIC, which is different than the 5-tuple. Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten.

This also means the kernel, which could previously steer traffic to a connection onto a single core. Realistically, QUIC will need a BPF filter to inspect the connection identifier and steer to the same core in the event of an IP address change.

All this is to say: I don't think most software is ready for QUIC, even if the protocol allows for cool things.

> Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten.

Yeah, but I don't think that's a hard thing to do, realistically speaking. Instead of mapping a source ip/port to a destination in the LB it's mapping a QUIC session ID instead.

> This also means the kernel, which could previously steer traffic to a connection onto a single core.

Most likely the kernel will not be rewritten to support this, since QUIC is a user space protocol. Also, the LB might just be able to rewrite the packet so it looks like it came from the LB when it sends it on to the server. The end server would never see the ip address change.

As browsers adopt it I'm sure uptake will be significant given the advantages. I'm looking forward to IP roaming.

as a security person I'm looking forward to massive holes in IP roaming implementations.

Corporate web proxies/filters will likely lag as well. https://support.forcepoint.com/KBArticle?id=000015410

AWS was working on UDP load balancing last year. [1] So, maybe 2021 GA.

[1] https://forums.aws.amazon.com/thread.jspa?threadID=264282

Azure's load balancers support UDP.

I believe Akamai has implemented QUIC but I haven't heard of any other CDNs that have.

A few other CDNs have implementations, but presumably we'll see much wider adoption once it has been standardised.

Cloudflare is also already testing draft QUIC support.

EdgeCast supports QUIC as well

https://www.verizondigitalmedia.com/blog/2018/05/quic-announ...

Reply on news.ycombinator.com