3 ms·

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

by jeltz 5y ago

mobilemidget 5y ago
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)
- viraptor 5y ago
  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.
  - Vecr 5y ago
    If I remember the amplification is about 3x, you need acks for the server to send more than that.
- serendipitous 5y ago
  > 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.
midasuni 5y ago
Wasn’t that the whole reason behind improved congestion algorithms like bbr which no longer assumed minor packet loss was the sign of congestion?
wahern 5y ago
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 https://www.rfc-editor.org/rfc/rfc9002.txt and https://datatracker.ietf.org/doc/html/rfc6582 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.
- kevincox 5y ago
  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).

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

by jeltz 5y ago

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

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)

viraptor 5y ago
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.
- Vecr 5y ago
  If I remember the amplification is about 3x, you need acks for the server to send more than that.
serendipitous 5y ago
> 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.

midasuni 5y ago

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

wahern 5y ago

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 https://www.rfc-editor.org/rfc/rfc9002.txt and https://datatracker.ietf.org/doc/html/rfc6582 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.

kevincox 5y ago
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).