3 ms·

The article states the following about TCP Reno: "It over-corrects on loss and leaves available path capacity idle – 10Gbps rates over 100ms RTT demands a pac

The article states the following about TCP Reno: "It over-corrects on loss and leaves available path capacity idle – 10Gbps rates over 100ms RTT demands a packet loss rate of less than 0.000003% – An average 1% loss rate over a 100ms RTT can’t operate faster than 3Mbps" Can someone explain the math there to me? I looked at the slides and I'm not seeing it. Am I missing something really obvious?

apenwarr 9y ago
Here’s a tool showing basically all the factors affecting maximum speed with traditional tcp: https://wand.net.nz/~perry/max_download.php https://wand.net.nz/~perry/max_download.php In short, the higher the loss, the slower it goes. The longer the rtt, the more loss sensitive it becomes. BBR avoids both of these flaws.
- bogomipz 9y ago
  This is a fantastic resource! Thanks.
jsnell 9y ago
An additive increase/multiplicative decrease congestion control algorithm has the property that the effect of a packet loss gets larger as the congestion window increases. There will be a point where the upward and downward forces on the congestion window balance out. The actual congestion window will oscillate around that. Assuming packet loss halves the congestion window while a packet delivery increases the congestion window by 1/cwnd, the break-even point for 1% packet loss is at a congestion window of 14. (1% change of reducing congestion window by 7, 99% chance of increasing it by 0.07). At 100ms RTT the average delivery rate will then be about 14 packets/rtt * 1500 bytes/packet * 10 rtts/second = 200kB/s. What if we cut down the packet loss rate by a factor of 10, to 0.1%? It won't give a 10x speed increase; instead the break-even point for the congestion window will be about 45; only a 3x increase in speed. If RTT is constant, increasing speed by 10x would require reducing packet loss by 100x. (The math here is simplified, but should suffice for illustrating this).
- bogomipz 9y ago
  Thank you yes this makes perfect sense, this is indeed the sawtooth pattern you see with AIMD. Cheers.
doctorsher 9y ago
While other commenters have given excellent answers, I just want to point out that these numbers probably fall out of the Mathis model of TCP throughput. Here's an article on the topic: https://blog.thousandeyes.com/a-very-simple-model-for-tcp-throughput/ https://blog.thousandeyes.com/a-very-simple-model-for-tcp-th...

apenwarr 9y ago

Here’s a tool showing basically all the factors affecting maximum speed with traditional tcp: https://wand.net.nz/~perry/max_download.php https://wand.net.nz/~perry/max_download.php In short, the higher the loss, the slower it goes. The longer the rtt, the more loss sensitive it becomes. BBR avoids both of these flaws.

bogomipz 9y ago
This is a fantastic resource! Thanks.

jsnell 9y ago

An additive increase/multiplicative decrease congestion control algorithm has the property that the effect of a packet loss gets larger as the congestion window increases. There will be a point where the upward and downward forces on the congestion window balance out. The actual congestion window will oscillate around that. Assuming packet loss halves the congestion window while a packet delivery increases the congestion window by 1/cwnd, the break-even point for 1% packet loss is at a congestion window of 14. (1% change of reducing congestion window by 7, 99% chance of increasing it by 0.07). At 100ms RTT the average delivery rate will then be about 14 packets/rtt * 1500 bytes/packet * 10 rtts/second = 200kB/s. What if we cut down the packet loss rate by a factor of 10, to 0.1%? It won't give a 10x speed increase; instead the break-even point for the congestion window will be about 45; only a 3x increase in speed. If RTT is constant, increasing speed by 10x would require reducing packet loss by 100x. (The math here is simplified, but should suffice for illustrating this).

bogomipz 9y ago
Thank you yes this makes perfect sense, this is indeed the sawtooth pattern you see with AIMD. Cheers.

doctorsher 9y ago

While other commenters have given excellent answers, I just want to point out that these numbers probably fall out of the Mathis model of TCP throughput. Here's an article on the topic: https://blog.thousandeyes.com/a-very-simple-model-for-tcp-throughput/ https://blog.thousandeyes.com/a-very-simple-model-for-tcp-th...