3 ms·

> packets are queued for a long time during congestion instead of being dropped quickly. This misleads TCP congestion control and leads to even more congestion.

by eps 15y ago

> packets are queued for a long time during congestion instead of being dropped quickly. This misleads TCP congestion control and leads to even more congestion. The last statement is true only for TCP/Reno. Reno here refers to a congestion detection algorithm, and it is that of looking for packet loss to recognize the congestion. This is the simplest and oldest approach, and it has been suceeded by TCP/Vegas, which looks at delivery delays instead, or how it is called a congestion avoidance algorithm. Basically the idea is that if the route gets congested, there will be buffeting happening at some hop and that would cause the RTT along the route to climb up. This being said, I don't know the split between Reno and Vegas adoption in the real world. However I think newer Windows versions are on Vegas.

tptacek 15y ago
This critique of Vegas by VJ is pretty famous (I love that you still have to FTP to ftp.ee.lbl.gov to get it): ftp://ftp.ee.lbl.gov/email/vanj.94mar14.txt
- NateLawson 15y ago
  I've got a copy of that on my mirror, including the postcript diagram: http://root.org/ip-development/e2e/end19940314-diagram.ps http://root.org/ip-development/e2e/end19940314-diagram.ps In summary, RTT variance as a congestion signal is actually quite bad. It's normal to have variation even without congestion, so utilization would be worse if you backed off every time RTT increased.
  - huhtenberg 15y ago
    From my completely unscientific tinkering with Vegas idea few years ago I remember that there was an easily detectable pattern in RTT change during the congestion. I was testing using UDP between my home and a colo server and I saw RTT climb up to several times its original level in a matter of two round trips. > It's normal to have variation even without congestion Certainly, but the question is if congestion-based variation is substantially different from an ambient variation. I am guessing that it is. Reacting to just a RTT increase is pretty dumb. The congestion marker clearly needs to be a bit more advanced than that.
wmf 15y ago
Vegas (and uTP and LEDBAT) tends to get outcompeted by Reno variants, so people generally only use it when they're trying to be "nice".
foobarbazetc 15y ago
Linux these days defaults to CUBIC anyway.

by eps 15y ago

tptacek 15y ago

This critique of Vegas by VJ is pretty famous (I love that you still have to FTP to ftp.ee.lbl.gov to get it): ftp://ftp.ee.lbl.gov/email/vanj.94mar14.txt

NateLawson 15y ago
I've got a copy of that on my mirror, including the postcript diagram: http://root.org/ip-development/e2e/end19940314-diagram.ps http://root.org/ip-development/e2e/end19940314-diagram.ps In summary, RTT variance as a congestion signal is actually quite bad. It's normal to have variation even without congestion, so utilization would be worse if you backed off every time RTT increased.
- huhtenberg 15y ago
  From my completely unscientific tinkering with Vegas idea few years ago I remember that there was an easily detectable pattern in RTT change during the congestion. I was testing using UDP between my home and a colo server and I saw RTT climb up to several times its original level in a matter of two round trips. > It's normal to have variation even without congestion Certainly, but the question is if congestion-based variation is substantially different from an ambient variation. I am guessing that it is. Reacting to just a RTT increase is pretty dumb. The congestion marker clearly needs to be a bit more advanced than that.

wmf 15y ago

Vegas (and uTP and LEDBAT) tends to get outcompeted by Reno variants, so people generally only use it when they're trying to be "nice".

foobarbazetc 15y ago

Linux these days defaults to CUBIC anyway.