
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.