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