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

[Steven Low]

Hi Les and Bill

Thanks for the very interesting experiments at SLAC.

This is an important question, which we don't understand
fully yet, and which we plan to study carefully later.   We'd
like to understand the underlying dynamics in the network
that manifest itself as the resulting sharing among different
TCP variants as Les observed in production networks.

One possible option is to make FAST behave
exactly like standard AIMD when window is small so that it's
compatible, as suggested by Sally.   Another option is to make
it "polite" and allow the standard AIMD flows, which are
presumably small flows, to grab what bandwidth they want
and take the remaining (hopefully big) chunk.  This is
certainly an unresolved issue with FAST TCP.

Steven



Cottrell, Les wrote:

>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
>
>
>>
>
>

-- 
_____________________________________________
Steven Low                assoc prof, cs & ee
netlab.caltech.edu        tel: (626) 395-6767
slow at caltech.edu          fax: (626) 568-3603