3 ms·

The post didn't discuss The backoff behavior of QUIC. For TCP, a dropped packet results in a halving of the data rate to help with assumed congestion of the net

The post didn't discuss The backoff behavior of QUIC. For TCP, a dropped packet results in a halving of the data rate to help with assumed congestion of the network. Does QUIC act as a good network citizen? Are they experimenting with different approaches?

serialx 10y ago
QUIC uses TCP friendly backoff algorithm called CUBIC. Linux TCP implementation currently uses CUBIC too. One difference between TCP and QUIC is that the parameter beta of CUBIC is different. One QUIC connection is equivalent to two TCP connections in that regard. So QUIC will only backoff half amount compared to TCP. In the design docs, they mention it's okay since one QUIC connection is equivalent to multiple TCP connections that a browser makes.
jwr 10y ago
My thoughts exactly. It's easy to get better performance than TCP if you're the only one using a different protocol and don't care about others. People have been doing that for years, using UDP and forward error correction (transform your data, embed error correcting codes, stuff the pipe with your data as quickly as you can, and hope that the other end will recover enough to reconstruct the original). What happens when we all move to QUIC or whatever else?
r1ch 10y ago
TCP congestion control is one of the main offenders in holding back high speed broadband. It can take minutes for TCP to discover the link bandwidth and a single lost packet can cut performance in half and the ramp back up to full speed may never happen. Is congestion collapse still a risk on today's internet? Do we need such aggressive congestion control?
- wtallis 10y ago
  Congestion control is as important as ever. Your packets can traverse links of just a few Mbps then 1Gbps then back down to a few Mbps, all within your own house on the way from your computer to your ISP's network. Common consumer networking equipment will do extremely stupid things in the face of congestion, such as storing packets in a FIFO buffer more than one second long. Initial window sizes still need to be small because there will always be users at the fringes of a wireless network where speeds are low enough that a burst of a few dozen full-size packets is a major call-dropping problem. The best solution is for AQM and ECN to be deployed widely, so that congestion can be identified and dealt with before it gets bad enough to require drastic rate decreases. QUIC currently cannot use ECN because those bits of the IP header typically aren't accessible from the APIs for UDP. Modern TCPs operating on networks that keep buffering delays low and signal congestion without dropping packets don't have trouble determining link bandwidth quickly.
vvanders 10y ago
Yeah, also: MTU discovery? Last time I did UDP this was a huge pain to do and required quite a few round-trips to get right. FEC isn't going to save you here as none of your packets are going to make it to the host. Or do they just fix it at 576 and not try to get any better efficiency from larger packets?

serialx 10y ago

QUIC uses TCP friendly backoff algorithm called CUBIC. Linux TCP implementation currently uses CUBIC too. One difference between TCP and QUIC is that the parameter beta of CUBIC is different. One QUIC connection is equivalent to two TCP connections in that regard. So QUIC will only backoff half amount compared to TCP. In the design docs, they mention it's okay since one QUIC connection is equivalent to multiple TCP connections that a browser makes.

jwr 10y ago

My thoughts exactly. It's easy to get better performance than TCP if you're the only one using a different protocol and don't care about others. People have been doing that for years, using UDP and forward error correction (transform your data, embed error correcting codes, stuff the pipe with your data as quickly as you can, and hope that the other end will recover enough to reconstruct the original). What happens when we all move to QUIC or whatever else?

r1ch 10y ago

TCP congestion control is one of the main offenders in holding back high speed broadband. It can take minutes for TCP to discover the link bandwidth and a single lost packet can cut performance in half and the ramp back up to full speed may never happen. Is congestion collapse still a risk on today's internet? Do we need such aggressive congestion control?

wtallis 10y ago
Congestion control is as important as ever. Your packets can traverse links of just a few Mbps then 1Gbps then back down to a few Mbps, all within your own house on the way from your computer to your ISP's network. Common consumer networking equipment will do extremely stupid things in the face of congestion, such as storing packets in a FIFO buffer more than one second long. Initial window sizes still need to be small because there will always be users at the fringes of a wireless network where speeds are low enough that a burst of a few dozen full-size packets is a major call-dropping problem. The best solution is for AQM and ECN to be deployed widely, so that congestion can be identified and dealt with before it gets bad enough to require drastic rate decreases. QUIC currently cannot use ECN because those bits of the IP header typically aren't accessible from the APIs for UDP. Modern TCPs operating on networks that keep buffering delays low and signal congestion without dropping packets don't have trouble determining link bandwidth quickly.

vvanders 10y ago

Yeah, also: MTU discovery? Last time I did UDP this was a huge pain to do and required quite a few round-trips to get right. FEC isn't going to save you here as none of your packets are going to make it to the host. Or do they just fix it at 576 and not try to get any better efficiency from larger packets?