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

From: "Fil Dickinson" <[email-masked]>
Date: Fri, 16 Jun 2006 10:59:25 +1000

I am not sure that I understand the operation of Quickstart correctly,
but I do have a concern that it does not adeqautely consider VoIP flows.

Could you answer a question on three different use cases?
i) A largish codec like G.711, and a poor RTT of 320ms. 
ii) A smaller codec like G.729a, and an acceptable RTT of 150ms.
iii) A small codec like G.723.1 ACELP, and a good RTT of 30ms.

Will each of these have their lowest QS rate restricted to 80kb/s?

If so, I am concerned that QS will degrade the applications performance.

-----Original Message-----
From: Mark Allman [mailto:[email-masked]] 
Sent: Friday, 16 June 2006 12:16 AM
To: [email-masked]
Cc: [email-masked]; Sally Floyd
Subject: Re: [Tsvwg] Re: Comments on rev-03: Quick-Start for TCP & IP 

> So I'm thinking about non-TCP applications, such as media streams: To 
> me, VoIP traffic of the order of 20-40 kbps doesn't perhaps appear 
> that odd.

Even for things like TFRC and DCCP we have mapped TCP's initial sending
rate onto them, right?  And, that standard initial rate is >= 40kbps
until the RTT gets longer than 855msec (or >= 20kbps until the RTT is
longer than 1.7sec).  

Or, to go the other way to even be worthwhile to request the current
lowest rate of 80kbps the RTT needs to be at least 427msec.  (I.e., if
the RTT is lower then the standard initial sending rate will be faster.)

These RTTs seem to me to make these things very much corner cases.

I think we're going to have to agree to disagree here.  If others have
an opinion, please jump in.

allman

---

From: Mark Allman <[email-masked]>
Date: Thu, 15 Jun 2006 22:39:48 -0400

> I am not sure that I understand the operation of Quickstart correctly,

Please take a pass at the i-d.  But, just to be quite clear ...

> Will each of these have their lowest QS rate restricted to 80kb/s?

No.

  + QS does not restrict sending rates to any given set.  There is a set
    (outlined in the i-d) of sending rates that can be requested.  But,
    the rate can then be adjusted using standard CC schemes.

  + QS is about shortening slow start when the nodes along the network
    path agree.  That is, the real point of QS is to eliminate the many,
    many RTTs it would take to build to a rate of (say) tens of Mbps
    over a network that is underutilized and can support such a
    session. 

  + No flow would have to use QS.  If one just wants to let the normal
    slow start-ish procedures work their magic then that's fine.

  + I'd need more details about the cases above (packet size, target
    sending rate) to say how QS might help (or not) those cases.

  + The point being discussed is that the lowest rate that can be
    requested using QS is 80kpbs.  Gorry's argument is that in some
    quite long and quite thin networks it could be useful to be able to
    request 40kbps (which would be higher than the standard initial
    sending rate).  But, you need a pretty long RTT to get into the
    regime whereby 40kbps is not covered by the standard initial
    setting.

I hope that helps.

allman