[iccrg-slowstart 00008] Re: [Iccrg] SSDT contributions

[Michael Scharf]

Dirceu,

the Quick-Start spec (RFC 4782, p. 10) allows only rather coarse
grained requests such as 5.12 Mbit/s, 10.24 Mbit/s, ..., 81.92 Mbit/s,
etc.

In the presented experiments, the admission control threshold has been
configured for a link capacity of 10 Mbit/s or 100 Mbit/s,
respectively.  Our Quick-Start admission control reduces or denies
larger requests, and it prevends overbooking. Whatever data rate is
asked for, 5.12 Mbit/s or 81.92 Mbit/s is the maximum request that
will get approved by the admission control.

But, even though the approved rate is smaller than the link capacity
of the setup, the Quick-Start performance is very close to the
theoretical optimum. The reason is that the sender continues to open
its window in Slow-Start after completing the Quick-Start phase. Thus,
it requires at most one additional RTT to send with the full speed.

A "perfect" scheme that exactly knows the optimal initial sending rate
would only slighly improve the application response time (it's very
simple to calculate this theoretical optimum).

Michael


On Tue, 15 Apr 2008 at 22:22:57, Dirceu Cavendish wrote:
> Michael,
> 
> Good charts. Question: how did you pick the specific 82Mbps and 5.1Mbps request values? Why didnt you request 9Mbps on a 10Mbps link?
> 
> Dirceu
> 
> 
> 
> ----- Original Message ----
> From: Michael Scharf <michael.scharf at ikr.uni-stuttgart.de>
> To: iccrg-slowstart at infonet.cse.kyutech.ac.jp
> Cc: iccrg IRTF list <iccrg at cs.ucl.ac.uk>
> Sent: Tuesday, April 15, 2008 12:33:04 PM
> Subject: [iccrg-slowstart 00007] Re: [Iccrg] SSDT contributions
> 
> Dirceu,
> 
> in simple usage scenarios (e. g., HTTP/1.0-like communication) the
> impact of Slow-Start is rather obvious, as well as the potential
> speedup that faster algorithms could achieve.
> 
> The attached slides show some Linux measurement results that compare
> the Slow-Start with Quick-Start (best case). There can be a
> performance improvement of one second or more, which is typically
> "user perceivable". The difference would be even larger if the TCP
> stacks used delayed ACKs (Linux disables them sometimes). Of course,
> the larger the RTT, the more significant is the effect.
> 
> I also have data for more realistic HTTP request patterns, but in this
> case the Slow-Start impact is more difficult to quantify and depends a
> lot on the application communication pattern.
> 
> Michael
> 
> On Fri, 11 Apr 2008 at 10:45:20, Dirceu Cavendish wrote:
> > Michael,
> > 
> > I think the "user perceivable" impact of faster SS algorithms should be documented within ICCRG. Do you have data backing that up (for any application of your choice)?
> > 
> > I am attaching few slides on experimental results in reducing segment losses during SS, for discussion. As presented in Manchester, we reduce losses by both reducing the speed of cwnd increase (in a fractional rather than by 1 way), as well as NOT transmitting the entire cwnd on a back-to-back fashion - introducing "micro-pauses" during transmissions...
> > 
> > Dirceu
> 
> 
>       ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-- 
Dipl.-Ing. Michael Scharf
Institute of Communication Networks and Computer Engineering  (IKR)
Universität Stuttgart, Pfaffenwaldring 47, 70569 Stuttgart, Germany
Phone: +49 711 685-69006 Email: michael.scharf at ikr.uni-stuttgart.de
Fax:   +49 711 685-67983 Web:   www.ikr.uni-stuttgart.de/en/~scharf