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

From: "Fil Dickinson" <[email-masked]>
Date: Tue, 20 Jun 2006 14:05:37 +1000

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

Is my understanding wrong?

If so I apologise, stand corrected and accept that there will be no
degradation to the current level of performance for app's with sub
80kb/s max bandwidth requirements.

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

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

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Jun 2006 08:54:18 -0400

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

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 Jun 2006 11:41:51 +0100

See below

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

I'm not sure the text needs to be changed.

Applications wishing to send at a rate less than 80 kbps need to decide what
to do: Either they just use standard CC, or they use a combination of
{standard CC AND a QS request with the minimum rate}.

If the choose {standard CC AND QS with the minimum rate}, then by sending
the QS request they simply ask the question "will the current router
commitments allow to send at the minimum rate?"

If the answer is "no" then they ignore the QS response. If the answer is
"yes" they use as much as they need up to the approved rate. The side-effect
may be that while the QS request is being requested/approved (a few RTT), a
router *could* follow how much resources are being committed using QS and
then may decline *other* QS requests should it believe no more capacity is
available. Other flows can use any "unused" capacity, QS does not reserve
capacity for flows.

The QS request (whatever the rate) will have no impact after a few RTT, what
matters then is the send rate allowed by CC.

Gorry

---

From: Mark Allman <[email-masked]>
Date: Wed, 21 Jun 2006 15:59:48 -0400

> Applications wishing to send at a rate less than 80 kbps need to
> decide what to do:

Let me try to step through.  Say an application wants to send at Xkbps
for some X < 80Kbps.

(1) The host can decide not to us QS.  In this case the standard initial
    sending rate applies and CC is carried out as it is now.

(2) The host can decide to send a QS request for 80Kbps (the closest
    request size to what it actually wants).

    (a) Some element in the network or the receiver can say "no".  QS
        will not be used and the standard initial sending rate applies
        and CC is carried out as it is now.

        (Note: When the rate request is > 80Kbps the network may also
        reduce the sending rate, but that is out of scope here because
        we're at the min rate request.)

    (b) The network and receiver can agree to support 80kbps.  The
        sender now calculates a QS-cwnd based on the approved rate
        (80kbps) and the measured RTT.

        (i) If QS-cwnd is smaller than the standard initial cwnd then
            QS-cwnd is ignored and the connection proceeds as the
            standard CC scheme allows.

            In this case, the application cannot use 80kbps (per the
            initial assumption above), but is allowed to send faster
            than 80kbps.  The router will then "allocate" (for QS
            purposes) 80kbps - Xkbps of bandwidth that will not be
            used.  That is 80-X kbps that cannot be given to another
            flow that requests QS until the "allocation" times out.

        (ii) If QS-cwnd is larger than cwnd then cwnd will be increased
             over its standard initial value.  However, now cwnd will be
             too big for the application to use because it will
             represent 80 kbps and the application wants X<80 kbps.
             While the new cwnd will not be fully used, depending on X
             the different between QS-cwnd and cend may represent an
             increase in the rate initial sending rate that will benefit
             the connection.  The router will then "allocate" (for QS
             purposes) 80kbps - Xkbps of bandwidth that will not be
             used.  That is 80-X kbps that cannot be given to another
             flow that requests QS until the "allocation" times out.

So, what we see is that in no case are we reducing the end host's
initial sending rate by using QS.  In some cases we may improve the
sending rate (ii).  And, in some cases there will be no change in the
initial sending rate (1,a,i).

As Gorry noted, the negative impact here is that the routers will
"allocate" too much bandwidth to the flow in certain cases and hence may
not be able to give that bandwidth to the competing flows.

I hope the sketch helps map the space.

allman

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Jun 2006 11:01:25 +0200

Hi,

Let me step in with a few comments on this (with my AD and chair hat off).

I don't think not supporting less than 80kbps is hurting anyone. However 
it does prevent some potential optimizations. However I think the case 
that are primarily limiting is one that uses TFRC. Lets assume that you 
have a one or more cellular link that result in fairly low bit-rate but 
a large RTT. In that case many VoIP applications would be interested in 
verifying that it can start at lets say 30kbps but using 50 packet per 
second. Most normal CC mechanisms neither TCP nor TFRC would allow to 
start with having 25 or 50 packets outstanding in the first RTT. But 
with quickstart knowing that you are not overdrafting the QS bit-rate 
you could do this. (assuming that you still think the routers are 
bit-rate limited rather than packet limited)

I don't say this is a case QS should be optimized for. Only say I think 
this is a potential use case for QS that are not well supported by the 
current spec. But I would wonder a bit how likely that someone would 
deploy an QS experiment on cellular links.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]