[e2e] Newbie question on impact of non-courteous TCP implemen tations

Cottrell, Les cottrell at SLAC.Stanford.EDU
Wed Jun 18 08:43:14 PDT 2003


I believe Steven Low (of FAST) is working on the fairness issues. 

We made some measurements (see http://www-iepm.slac.stanford.edu/monitoring/bulk/tcpstacks/) on production R&E nets comparing FAST, Scalable and New Reno (we still need to look at HS-TCP), but have not really addressed the fairness question. We do have some tentative information.

Comparing a single FAST stream with multipel parallel Reno streams (see http://www-iepm.slac.stanford.edu/monitoring/bulk/tcpstacks/fast-multi.html) it appears that the FAST stream (on a particular path - SLAC to CERN with 200ms RTT with 8MByte windows - with a 622Mbits/s capacity bottleneck, no RED) gets about 215 +- 15 Mbits/s fairly consistently (FAST against 1 Reno stream got 244+-80Mbits/s) while as one adds more Reno streams, Reno increased from  87Mbits/s (1 stream Reno) to about 150Mbits/s (8 streams of Reno, in this case FAST got 200+- 100Mbits/s, so FAST was possibly backing off).  This also identifies that the achievable bandwidth (8 streams Reno + 1 stream FAST) was at least 350Mbits/s. 

When comparing single stream FAST to single stream (see for example http://www-iepm.slac.stanford.edu/monitoring/bulk/tcpstacks/fast.html) on the same path as well as other paths (SLAC to NIKHEF, SLAC to Caltech, SLAC to APAN in Japan), FAST appears to outperform Reno, except in the case of Caltech where the large variation in RTTs caused Reno to outperform FAST. 

On the downside however, we also observed cases where a single stream Reno on its own (no competing FAST) on the SLAC CERN path, did much better (~200Mbits/s) than when competing vs FAST (Reno got ~45Mbits/s), see for example http://www.slac.stanford.edu/grp/scs/net/talk/19).

-----Original Message-----
From: Bill St. Arnaud [mailto:bill.st.arnaud at canarie.ca] 
Sent: Wednesday, June 18, 2003 5:48 AM
To: end2end-interest at postel.org
Subject: [e2e] Newbie question on impact of non-courteous TCP implementations


I am trying to find out if there has been any research done on the possible impact of some of the new TCP implementations (e.g. FAST TCP, TCP--Real, etc) on existing TCP implementations.

I would like to know if these new implementations might possibly starve out or seriously impair existing TCP flows that are using standard AIMD.  In the event of congestion a more aggressive AIMD will recover more quickly and therefore grab all the available bandwidth while the slower standard AIMD is still ramping back up (especially those with longer RTTs).  As these new TCP protocols are designed to support huge flows and utilize all the available bandwidth they could have a big impact on overall network performance.

I am assuming that these flows will be used only on R&E networks where there is no RED or similar back off mechanisms

Bill

---------
Bill.St.Arnaud at canarie.ca
starnau at attglobal.net
www.canarie.ca/~bstarn


>
>




More information about the end2end-interest mailing list