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

From: "Arjuna Sathiaseelan" <[email-masked]>
Date: Fri, 16 Jun 2006 21:07:57 +0100

I concur with Mark..From the simulations tests we have done here at
Aberdeen (TFRC using QS), we found that the QS would greatly reduce
the loss of packets that could be caused due to the mismatch between
the encoding rate of the voice app and the slowstart behaviour of TFRC
by increasing the sending rate to the encoding rate within one RTT (if
the routers approve the QS rate: the encoding rate of the app)  ..This
holds true for both the initial slowstart phase and after a silence
period...So infact QS would definitely improve the performance of
VoIP..

-Arjuna

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

-- 
Regards,
Arjuna

Postdoctoral Researcher
Engineering Research Lab,
Department of Engineering,
University of Aberdeen

---

From: Sally Floyd <[email-masked]>
Date: Tue, 20 Jun 2006 10:55:50 -0700

>Perhaps I have misunderstood the draft.
>My understanding is that if two hosts and the routers in between those
>hosts support quickstart, then they will try to use QS first and if this
>fails fall back to default congestion control mechanisms. I did not
>think that the RTT determined whether QS was used or not.
>I interpret that your draft proposes these systems will try QS even if
>they only need 20kb/s and then be told, to fall back as they will not be
>approved because it is less than the lower limit of 80kb/s.

If a host wishes, and the other transport end understands Quick-Start,
then the host can use Quick-Start.  Quick-Start does not replace
the congestion control mechanisms of the underlying transport
protocol; if a Quick-Start packet is dropped (Section 4.5), the
sender reverts to the default congestion control mechanism for that
transport protocol.  Similarly, with TCP, after a window of Quick-Start
packets have been sent following an approved Quick-Start request,
the sender reverts to using the default congestion control procedures
(Section 4.4).

The draft also says that Quick-Start does not give guaranteed
bandwidth.  From Section 3.3:  "That is, the approval by the router
of a Quick-Start request does not give differential treatment for
Quick-Start data packets at that router; it is only a statement
from the router that the router believes that the subsequent
Quick-Start data packets from this connection will not change the
current under-utilized state of the router."

So consider a flow using Quick-Start that only needs 20 kpbs.
If that flow can start-up on its own with an initial sending
rate of 20 kpbs without Quick-Start, then Quick-Start is of
no use to it.

So assume that the transport protocol doesn't allow the flow to
start-up with an initial sending rate of 20 kbps.  In this case,
the sender can send a Quick-Start request requesting 80 Kbps, the
smallest possible request.  If the router approves the request,
then the sender can send 20 kbps, and all will be fine.  The flow
will not in any way be harmed by Quick-Start's lower limit of 80
kbps on rate requests.  The Quick-Start router does not necessarily
keep per-flow state, and after a transient period of a second or
so, the fact that the sender is only sending 20 kbps will not make
it more difficult for subsequent flows to have their Quick-Start
requests approved.

The flow would only be harmed by the lower limit of 80 kbps if the
router *won't* approve a Quick-Start request of 80 kbps, but *would
have* approved a a Quick-Start request of 40 kbps or of 20 kbps.
If this is the case, then the flow won't be able to use Quick-Start,
and will have to make due with whatever start-up is allowed by its
transport protocol.

So in summary, for a flow that has a sending rate of 20 kbps, the
flow would find Quick-Start useful only if the transport protocol does
not allow it to start with a sending rate of 20 kbps without
Quick-Start.  And the flow would find Quick-Start's lower limit of
80 kbps on rate requests limiting only in a case where the routers
would have approved a smaller Quick-Start request, but would not 
approve a Quick-Start request of 80 kbps.

However, routers are only supposed to approve Quick-Start requests
if they are significantly underutilized.  So my assumption would
be that the lower limit of 80 kbps for Quick-Start requests would
not prevent many Quick-Start requests from being approved,
in typical scenarios.  

- Sally

---

From: "Fil Dickinson" <[email-masked]>
Date: Wed, 21 Jun 2006 09:45:53 +1000

Thank you for this illuminating explaination.
Apologies for my ignorance or any annoyance I may have caused the
authors. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, 21 June 2006 3:56 AM
To: Fil Dickinson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Tsvwg] Re: Comments on rev-03: Quick-Start for TCP & IP 

>hosts support quickstart, then they will try to use QS first and if 
>this fails fall back to default congestion control mechanisms. I did 
>not think that the RTT determined whether QS was used or not.
>they only need 20kb/s and then be told, to fall back as they will not 
>be approved because it is less than the lower limit of 80kb/s.

If a host wishes, and the other transport end understands Quick-Start,
then the host can use Quick-Start.  Quick-Start does not replace the
congestion control mechanisms of the underlying transport protocol; if a
Quick-Start packet is dropped (Section 4.5), the sender reverts to the
default congestion control mechanism for that transport protocol.
Similarly, with TCP, after a window of Quick-Start packets have been
sent following an approved Quick-Start request, the sender reverts to
using the default congestion control procedures (Section 4.4).

The draft also says that Quick-Start does not give guaranteed bandwidth.
>From Section 3.3:  "That is, the approval by the router of a Quick-Start
request does not give differential treatment for Quick-Start data
packets at that router; it is only a statement from the router that the
router believes that the subsequent Quick-Start data packets from this
connection will not change the current under-utilized state of the
router."

So consider a flow using Quick-Start that only needs 20 kpbs.
If that flow can start-up on its own with an initial sending rate of 20
kpbs without Quick-Start, then Quick-Start is of no use to it.

So assume that the transport protocol doesn't allow the flow to start-up
with an initial sending rate of 20 kbps.  In this case, the sender can
send a Quick-Start request requesting 80 Kbps, the smallest possible
request.  If the router approves the request, then the sender can send
20 kbps, and all will be fine.  The flow will not in any way be harmed
by Quick-Start's lower limit of 80 kbps on rate requests.  The
Quick-Start router does not necessarily keep per-flow state, and after a
transient period of a second or so, the fact that the sender is only
sending 20 kbps will not make it more difficult for subsequent flows to
have their Quick-Start requests approved.

The flow would only be harmed by the lower limit of 80 kbps if the
router *won't* approve a Quick-Start request of 80 kbps, but *would
have* approved a a Quick-Start request of 40 kbps or of 20 kbps.
If this is the case, then the flow won't be able to use Quick-Start, and
will have to make due with whatever start-up is allowed by its transport
protocol.

So in summary, for a flow that has a sending rate of 20 kbps, the flow
would find Quick-Start useful only if the transport protocol does not
allow it to start with a sending rate of 20 kbps without Quick-Start.
And the flow would find Quick-Start's lower limit of 80 kbps on rate
requests limiting only in a case where the routers would have approved a
smaller Quick-Start request, but would not approve a Quick-Start request
of 80 kbps.

However, routers are only supposed to approve Quick-Start requests if
they are significantly underutilized.  So my assumption would be that
the lower limit of 80 kbps for Quick-Start requests would not prevent
many Quick-Start requests from being approved, in typical scenarios.  

- Sally

---

From: "Fil Dickinson" <[email-masked]>
Date: Wed, 21 Jun 2006 09:45:53 +1000

No Mark, 
Thanks a lot.
As per my response to Sally, I am clear now. 
Once again sorry for misunderstanding. 

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

> Is my understanding wrong?

Yes, I think so.  See equation (3) and surrounding text.  The document
seems pretty clear to me (!) on this point.  When a valid response is
received we calculate a QS-cwnd based on the approved sending rate and
the measured RTT.  The document then says:

    The TCP host SHOULD set its congestion window cwnd to QS-cwnd only
    if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored.

At this point cwnd would be the standard initial cwnd.  So, basically
this means that QS can only *increase* the rate.  If one were going to
use this in some non-TCP context then I think one would use the same
principle, but it might not be precisely the same mechanism (e.g., maybe
the step to go from rate to window would not be needed).

Is there something else we should say / make more clear?

allman