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

From: "Fil Dickinson" <[email-masked]>
Date: Fri, 16 Jun 2006 14:35:58 +1000

Thanks, it helps a lot with my understanding of the ID (which I find a
bit daunting). 
Though it may not impact RTP based VoIP, I do think that it might (if
enabled at the nodes involved) degrade the initial performance of
applications that have a very deterministic rate and shape to their
packet size, have sub 80kb/s max bandwidth needs and require low delay,
loss and jitter of the network. In such cases folks need to be aware of
any operational impact before enabling QS.

My answers to your point on packet sizes, etc. for the use cases is in
the table I use below:
________________________________________________________________________
______________________
| codec | bit rate | payload | ip frame | pack size eth | pack size
eth+aal5atm | atm size    |
------------------------------------------------------------------------
----------------------
| G.711 | 64kb/s   | 160Bytes| 200Bytes | 218Bytes      | 234Bytes
| 265Bytes    |
| G.729a| 8kb/s    | 20Bytes | 60Bytes  | 78Bytes       | 94Bytes
| 106Bytes    |
| G.723 | 6.3kb/s  | 16Bytes | 56Bytes  | 74Bytes       | 90Bytes
| 106Bytes    |
------------------------------------------------------------------------
----------------------
This table assumes a sampling rate of 20ms for all three codecs.

Thanks again.

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

> 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 ...

> 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?

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

---

From: Mark Allman <[email-masked]>
Date: Fri, 16 Jun 2006 08:07:10 -0400

> packet size, have sub 80kb/s max bandwidth needs and require low
> delay, loss and jitter of the network. In such cases folks need to be
> aware of any operational impact before enabling QS.

Can you say more about this?  How would QS degrade application
performance in these cases?

The only two ways I can see that QS ought to *degrade* performance are:

  * A packet with a QS request may take the 'slow path' through a
    router, which may slightly increase the overall RTT of the path for
    that packet.  (This would seem to me to be a quite slight impact in
    the overall scheme of things.)

  * QS allows a host to send at some rate and ultimately that rate leads
    to congestion (loss) and so the host has to backoff to slow start.
    In this case, overall performance may or may not be degraded
    relative to simply starting with the normal startup procedure.

How would QS degrade performance of sub 80Kbps flows?  These flows
aren't in the realm of even thinking about using QS unless the RTT is
*very* long to begin with.

It would be helpful if you sketched some specifics about this
degradation. 

Thanks,
allman