Hacker News Reader

Comment by jeltz | Hacker News Reader

For unreliable networks we do need it. TCP has always performed poorly when there is a lot of packet loss.

That all depends on the congestion control algorithm. Different implementations of TCP can use different algorithms while still being compatible. The same is true of QUIC.

The recently published QUIC standard specifies a tweaked version of TCP NewReno. See https://www.rfc-editor.org/rfc/rfc9002.txt and https://datatracker.ietf.org/doc/html/rfc6582 But AFAIU this is not the algorithm Google itself uses for QUIC, nor the one they used for their famous benchmarks showing latency improvements on mobile.

To derive maximum benefit (or even just most of the benefit) of a tailored congestion control algorithm, you'll want to control both sides, keeping them in sync as you iterate improvements and changes. And maintain different flavors for different application environments. Only huge companies like Google and Facebook will be able to do this effectively.

QUIC does have more than just different congestion control For example it has forward error correction which can be very important for lossy connections.

There are other improvements that can't really be added to TCP either such as roaming between IP addresses. (MPTCP exists but IIUC requires make-before-break which is not always possible).

My personal opinion would prefer to improve those networks vs going UDP for http(s). Until spoofing, amplification attacks on UDP are properly tackled and not causing most internet outages, I'm not really looking forward to a UDP web (http/3)

Does http3 have a problem with amplification on the first answer packet?

I'm not sure spoofing is something transport protocols have to solve though. Authenticated bgp and source filtering is the layer for it and we needed it for decades already.

If I remember the amplification is about 3x, you need acks for the server to send more than that.

> Until spoofing, amplification attacks on UDP are properly tackled

This is already addressed by QUIC (the transport protocol used by HTTP/3). Those things are no more of a problem for HTTP/3 than they are for HTTP/2 or HTTP/1.

Wasn’t that the whole reason behind improved congestion algorithms like bbr which no longer assumed minor packet loss was the sign of congestion?

Reply on news.ycombinator.com