[Iccrg] SSDT Scope

[Dirceu Cavendish]

Injong,

I did not mean to say that this is a problem of SS ONLY. TCP is also biased to rtts...
In case of SS, there is a cwnd size over which the source becomes effectively limited by its interface speed, not the cwnd value, any longer. And the larger the RTT is, the higher this value becomes.
So, sessions with shorter RTTs will achieve this "interface speed" ceiling sooner than later, hence SS bias towards shorter RTT sessions...

Also, in my view, we do not have a MAIN problem as yet. All we are trying to do is to come up with a laundry list of SS limitations. We may not be able to work on all of them, and hence it is important to discuss the relevance of the issues as they come up. I have my preferences, and I certainly would rank the multiple segment losses, non-smooth transition between SS and CA higher in my list. But it also bothers me when experimenting with multiple RTT sessions, and one grabs most of the bottleneck baidwidth, starving others.

Dirceu



----- Original Message ----
From: Injong Rhee <rhee at ncsu.edu>
To: iccrg at cs.ucl.ac.uk
Sent: Wednesday, March 26, 2008 12:04:07 PM
Subject: Re: [Iccrg] SSDT Scope

>>- Unfairness with different session RTTs.

Why is this a problem with slow start? I guess that the main subject  
is that the original SS is too aggressive as it doubles cwnd by 2 (or  
some factor close to it due to delayed acks) per RTT, and under large  
BDP, there are a huge number of packets overshot at the time of  
losses. The question is how to detect when to finish the ss and  
transit to ca so that we don't have such high losses. 

_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/bbfdf72d/attachment.html