Subject: Re: [Fwd: [Tsvwg] Re: Comments on rev-03: Quick-Start for TCP & IP]

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 05 Jun 2006 17:00:34 +0100

To me the issue of a sensible starting value for QS is simply 
<initial-window>/<PRTT>

Where the window is the initial window that would be allowed for TCP
and PRRT is path round trip time - e.g. somewhere betwen 10ms and 3 secs;-)

So given a new TCP flow can send this much, any other method friendly to 
TCp can also send this much without the need for QS.

So, this value ranges from 1.77 Mbps (for 10ms PRTT)
to 12 kbps (for 3 secs PRTT).

So I guess I am saying that the minimum QS rate of 80 kbps is an order 
of magnitude greater than you might expect TCP to get over a long (e.g. 
~3 seconds) delay link. A link delay of this order is not uncommon for 
BoD-style wireless networks (especially at the start of a flow). That 
was motivation for suggesting that 40 kbps was also a useful QS rate.

Gorry

Arjuna Sathiaseelan wrote:

> Oops - I think I have muddled it up! Sorry! By increasing the sampling 
> interval, we actually end up having smaller bit rates! I got my 
> calculation wrong there!
>  
> -Arjuna
> 
> 
>  
> On 5/25/06, Arjuna Sathiaseelan <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Dear Sally,
>       I guess what you said holds true for high bit rate codecs such as
>     the G.711 which encodes at 64Kbps. But there are several codecs such
>     as the G728, G.729a, AMR which use very low bit rates. For eg a
>     G.729 codec could need 16Kbps (assuming 2 * 10ms intervals) or
>     32Kbps (assuming 4*10ms intervals) + header size for the packets.
>     Moreover with the advent of Robust header compression techniques,
>     the required rate would be reduced. So we believe that having a
>     80Kbps rate would be high if these type of low bit rate
>     apps requiring to use QS to improve their performance.
>      
>     Regards,
>     Arjuna
> 
> 
> 
>         Good question.
> 
>         Let's assume that no apps need to send small packets more
>         frequently than
>         every 20 ms.  RFC 3390 pretty much takes care of the needs of a
>         flow with
>         a 100 ms RTT, allowing an initial window of four small packets,
>         so let's
>         assume a flow with a 200 ms RTT.  The current
>         lowest rate of 80 kbps (= 10 kBps) allows an initial rate of 2000
>         bytes/RTT, or 10 200-byte packets per RTT.  RFC 3390 already
>         allows four
>         small packets per RTT, so the current low rate of 80 kbps is
>         roughly twice as large, for a flow with a 200 ms RTT.  My hit
>         would be
>         that allowing a lower rate request of 40 kbps isn't really
>         needed, even
>         for flows that send small packets every 20 ms.
> 
>         <snip>
> 
>         Many thanks for the feedback.
> 
>         - Sally
>         http://www.icir.org/floyd/
> 
> 
> 
> 
> 
>     -- 
>     Regards,
>     Arjuna
> 
>     Postdoctoral Researcher
>     Engineering Research Lab,
>     Department of Engineering,
>     University of Aberdeen 
> 
> 
> 
> 
> -- 
> Regards,
> Arjuna
> 
> Postdoctoral Researcher
> Engineering Research Lab,
> Department of Engineering,
> University of Aberdeen