[e2e] TCP un-friendly congestion control

[Injong Rhee]

Hi Craig,

Maybe there is some misunderstanding. Since TCP increases the congestion
window by one segment in each RTT, if the maximum window size is 4167,
then for TCP to reach that window size after a loss event, it would take
half of 4167 RTTs. 

I am also not talking about slow start; in steady state, cwnd reduces to
half of its current window at a loss event and increases by one after
that. I am just commenting on an extreme case where a single flow is
running on that network. I hope this clears our misunderstanding. 

Not sure where 18 RTT comes from??

Cheers,

Injong Rhee
Computer Science Dept
North Carolina State Univ.
rhee at csc.ncsu.edu
http://www.csc.ncsu.edu/faculty/rhee

> -----Original Message-----
> From: Craig Partridge [mailto:craig at aland.bbn.com]
> Sent: Friday, June 06, 2003 2:25 PM
> To: Injong Rhee
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] TCP un-friendly congestion control
> 
> 
> In message <000001c32c54$43ec4ae0$9d350e98 at HD>, "Injong Rhee" writes:
> 
> >My definition for fast, long distance networks might have been
perhaps
> >too liberal. In case of 1Gbps and 50ms, its B x D is 4167 packets
> >assuming 1500 byte packets. It will take around 2083 (4167 after
worst
> >case timeout) round trip times which is around 104 (208) seconds. If
the
> >delay increases to 100ms and 200ms, this becomes 6 min and 28 min. As
> >you scale the bandwidth to 10G, this becomes ...well..I guess that
> >should be enough.
> 
> I don't understand your logic here.
> 
> The bandwidth*delay product is indeed around 6,250,000 bytes which is
> 4167 segments.
> 
> The maximum TCP window size is 2^30 which is 1,073,741,824 or at least
> two orders of magnitude larger than required.
> 
> The number of round-trips required to reach this window size is
> approximately
> 18 RTTs, which is 0.9 seconds.
> 
> So... I don't see where 2083 RTTs comes from, nor 6 or 28 minutes.
> 
> Craig