Simplifying the TCP throughput algorithm
I did some extremely rough numerical experiments with the TCP throughput algorithm. Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates: 0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive) These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms). Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is: T = s / sqrt(p * 2/3) That's a simple formula. Harald
I suppose these were random losses?
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Thursday, March 29, 2012 1:04 PM To: rtp-congestion@alvestrand.no Subject: [R-C] Simplifying the TCP throughput algorithm
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Dear Harald, it's not that safe modifying the PFTK formula without breaking tcp-friendliness (if we want to be tcp-friendly, and I assume we want it). That formula mimics the long term behaviour of a TCP flow experiencing a specific RTT and packet loss ratio p. Not taking into account the RTT of the connection to estimate TCP throughput is quite dangerous. Cheers, Luca On Thu, Mar 29, 2012 at 1:07 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
I suppose these were random losses?
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Thursday, March 29, 2012 1:04 PM To: rtp-congestion@alvestrand.no Subject: [R-C] Simplifying the TCP throughput algorithm
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 03/29/2012 01:15 PM, Luca De Cicco wrote:
Dear Harald,
it's not that safe modifying the PFTK formula without breaking tcp-friendliness (if we want to be tcp-friendly, and I assume we want it). That formula mimics the long term behaviour of a TCP flow experiencing a specific RTT and packet loss ratio p. Not taking into account the RTT of the connection to estimate TCP throughput is quite dangerous. My point is that taking the RTT into account gives a change of less than 1% in the calculated value, for all the values I've tried; if you have a specific parameter combination in mind where the RTT makes a huge difference, please give the numbers you are thinking of.
Given the lack of knowledge we have of so many other factors that enter into the system (video rate, for instance, will jump by quite many percent when someone shakes the camera), an estimate with an error of less than 1% is a spectacularly good estimate for most purposes.
Cheers, Luca
On Thu, Mar 29, 2012 at 1:07 PM, Ali C. Begen (abegen)<abegen@cisco.com> wrote:
I suppose these were random losses?
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Thursday, March 29, 2012 1:04 PM To: rtp-congestion@alvestrand.no Subject: [R-C] Simplifying the TCP throughput algorithm
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
I suppose these were random losses? This is just putting numbers into the TCP throughput algorithm from the TCP-Friendly RFC using its parameter p, and trying to see what the implications of the result are.
I presume that p was assumed to be random in the derivation of the formula.
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Thursday, March 29, 2012 1:04 PM To: rtp-congestion@alvestrand.no Subject: [R-C] Simplifying the TCP throughput algorithm
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 29 Mar 2012, at 13:19, Harald Alvestrand wrote:
On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
I suppose these were random losses? This is just putting numbers into the TCP throughput algorithm from the TCP-Friendly RFC using its parameter p, and trying to see what the implications of the result are.
I presume that p was assumed to be random in the derivation of the formula.
It's a loss event rate. The equation gives a conservative value for the throughput if the loss is bursty. Colin
That formula was derived for TCP NewReno so it's not working properly for TCP Cubic for instance :). That's why I am not a fan of the TFRC approach. Cheers, Luca On Thu, Mar 29, 2012 at 1:22 PM, Colin Perkins <csp@csperkins.org> wrote:
On 29 Mar 2012, at 13:19, Harald Alvestrand wrote:
On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
I suppose these were random losses? This is just putting numbers into the TCP throughput algorithm from the TCP-Friendly RFC using its parameter p, and trying to see what the implications of the result are.
I presume that p was assumed to be random in the derivation of the formula.
It's a loss event rate. The equation gives a conservative value for the throughput if the loss is bursty.
Colin _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Hi, I think that the idea of saying standard TCP as a lower limit is a better basis than using CUBIC for that... if you want to be more aggressive, you can also just take our equation which mimics a number of TCPs. This seems to be a more appropriate basis than an experimental mechanism. Further, I agree with Colin - p is a loss event rate, not a packet loss rate. That difference can be significant, and it was probably the reason why someone asked whether the losses were random. This is also the reason why you don't get the throughput of 10 TCPs by multiplying that equation by 10, and why we had to make a new formula for that. Figure 2 of our IEEE/ACM ToN paper shows that difference, see: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1 If you have trouble accessing that, a similar figure is also in Dragana's Ph.D. thesis, which is a much larger pdf: http://heim.ifi.uio.no/~michawe/research/projects/multfrc/dragana_thesis.pdf - figure 3.18 on page 65. That thesis also has a deeper investigation of the impact of clustered vs. random losses. I agree with the simplification of using the packet loss ratio for p in the circuit breaker - there, I think it's reasonable, but only there. BTW, Harald - have you derived a variant of the simpler TCP equation that was once derived by a fellow Googler?! :-) http://www.psc.edu/networking/papers/model_ccr97.ps Cheers, Michael On Mar 29, 2012, at 1:26 PM, Luca De Cicco wrote:
That formula was derived for TCP NewReno so it's not working properly for TCP Cubic for instance :). That's why I am not a fan of the TFRC approach.
Cheers, Luca
On Thu, Mar 29, 2012 at 1:22 PM, Colin Perkins <csp@csperkins.org> wrote:
On 29 Mar 2012, at 13:19, Harald Alvestrand wrote:
On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
I suppose these were random losses? This is just putting numbers into the TCP throughput algorithm from the TCP-Friendly RFC using its parameter p, and trying to see what the implications of the result are.
I presume that p was assumed to be random in the derivation of the formula.
It's a loss event rate. The equation gives a conservative value for the throughput if the loss is bursty.
Colin _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Thu, Mar 29, 2012 at 1:22 PM, Colin Perkins <csp@csperkins.org> wrote:
On 29 Mar 2012, at 13:19, Harald Alvestrand wrote:
On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
I suppose these were random losses? This is just putting numbers into the TCP throughput algorithm from the TCP-Friendly RFC using its parameter p, and trying to see what the implications of the result are.
I presume that p was assumed to be random in the derivation of the formula.
It's a loss event rate. The equation gives a conservative value for the throughput if the loss is bursty.
Which is likely for queues employing tail dropping.
Colin _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 29 Mar 2012, at 13:38, Stefan Holmer wrote:
On Thu, Mar 29, 2012 at 1:22 PM, Colin Perkins <csp@csperkins.org> wrote: On 29 Mar 2012, at 13:19, Harald Alvestrand wrote:
On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
I suppose these were random losses? This is just putting numbers into the TCP throughput algorithm from the TCP-Friendly RFC using its parameter p, and trying to see what the implications of the result are.
I presume that p was assumed to be random in the derivation of the formula.
It's a loss event rate. The equation gives a conservative value for the throughput if the loss is bursty.
Which is likely for queues employing tail dropping.
Agree, but (at least from the measurements I've seen) the estimate won't be too bad. -- Colin Perkins http://csperkins.org/
On 29 Mar 2012, at 13:04, Harald Alvestrand wrote:
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Add the RTT, and you get the usual TCP throughput approximation. That seemed to be the suggestion to use from ICCRG. -- Colin Perkins http://csperkins.org/
On 03/29/2012 01:19 PM, Colin Perkins wrote:
On 29 Mar 2012, at 13:04, Harald Alvestrand wrote:
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Add the RTT, and you get the usual TCP throughput approximation. That seemed to be the suggestion to use from ICCRG. Ah - thanks for spotting the error!
It should be X = s / R * sqrt(2*p/3) - which makes a huge difference in my numbers, and makes the cost of the simplification grow to around 30% for the 10% loss cases. Still low when loss < 1%. This of course also makes the number of packets strongly dependent on the RTT, which seems consistent with the commonly held belief that TCP is RTT dependent. For the 100 ms RTT case (~transatlantic), the new numbers are: 0.001%: 45 Mbits 0.01%: 14 Mbits 0.1%: 4.5 Mbits 1%: 1.3 Mbits 10%: 284 Kbits So we can get rudimentary video through at 10% packet loss without being TCP-unfriendly, but for reasonable quality video, packet loss needs to be below 1% at this RTT. (I've tried TCP at 10% packet loss, real life, transatlantic RTT, back in the bandwidth crunch of the 90s. I didn't get 284 Kbits/sec, though.....) Full formula, copied from draft: s X = -------------------------------------------------------------- R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) with b=1 and t_RTO = 4 RTT.
Personally, I tend to think in terms of the upper bound on goodput, which is cwnd * pmtu rate = ------------- rtt Yes, actual goodput measured over the life of the session is a little less as described in the equation. In samples I have taken, my observation is that there might be hundreds to thousands of RTTs, and we drop a single digit number of packets - on the order of 1% of the RTTs have an actual throughput rate that differs from the upper bound. To my small mind, the impact of competing with a variable amount of competitive traffic has a much larger effect on goodput than loss. YMMV On Mar 29, 2012, at 1:04 PM, Harald Alvestrand wrote:
I did some extremely rough numerical experiments with the TCP throughput algorithm.
Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates:
0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive)
These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms).
Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is:
T = s / sqrt(p * 2/3)
That's a simple formula.
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
participants (7)
-
Ali C. Begen (abegen) -
Colin Perkins -
Fred Baker -
Harald Alvestrand -
Luca De Cicco -
Michael Welzl -
Stefan Holmer