Subject: Re: [Tsvwg] Re: draft-ietf-tsvwg-quickstart-00: Consideration of QSNONCE.

From: Sally Floyd <[email-masked]>
Date: Fri, 09 Sep 2005 20:34:11 -0700

Martin -

>Some editorial comments on the draft:
>
>1) End of Section 4.4: I had to read this several times to understand it
>completely (I believe). Perhaps you should add this sentence:
>  "If the TCP sender sets it congestion window to QS-cwnd, at the
>conclusion of Quick-Start Mode it remains at this value, and all ACKs
>are processed as if they were any other TCP ACK."
>   If I misunderstood, I suspect the specification is insufficiently
>clear.

You understand correctly, but that paragraph was not a good one.
I replaced it with the following:.

 If, during Quick-Start mode, the TCP sender receives ACKs for packets
 sent before this Quick-Start mode was entered, these ACKs are processed
 following the default congestion control mechanisms.

 ...
 After Quick-Start mode is exited and the congestion window adjusted
 if necessary, the TCP sender returns to using the default congestion 
 control mechanisms, processing further incoming ACK packets as  
 specified by those congestion control mechanisms.  For example, if
 the TCP sender was in slow-start prior to the Quick-Start request,
 and no packets were lost or marked since that time, then the sender  
 continues in slow-start after exiting Quick-Start mode, as allowed
 by ssthresh.

...
>2) Section 4.1. What is the policy on requesting additional QS
>allocations while one is currently ongoing?  Or is it that TCP senders
>MUST NOT do another request outside of the parameters of 4.1?  The MUST
>NOT statement would be a useful addition if true.

I added the following:

 In any circumstances, the sender MUST NOT make a QS request 
 if it has made a QS request within the most recent round-trip time.

I am reluctant to say that the sender MUST NOT do anything other
than 1-4, because even now there is the email thread on whether the
sender can resend a downgraded QS request after a request is
approved but downgraded in the network.

...
>3) Regarding the problem of arbitrarily large requested rates:
>	What is to prevent delay of the QS request until the amount of
>available data is clear?  For instance, a web server may request a data
>rate after it receives the HTTP request.  Surely the requests do not
>require QS, and requiring one additional RTT is not a huge price to pay.
>Even in the case of streaming open-ended data, a QS request will not be
>over the same time scales, so the TCP sender can request a window for
>the just the data it has in its buffer. Then we could add a sentence
>like this to 4.1:
>	"A TCP sender SHOULD NOT send a Quick-Start request until it has
>confirmed that is ready to transmit at least K/RTT bytes [K TBD based on
>a certain minimum file size]."

A good suggestion.  I added this:

 As a general guideline, a TCP sender SHOULD NOT send a Quick-Start 
 request until it has confirmed that is ready to transmit enough
 data to use the requested rate over the round-trip time of the
 connection (or over 100 ms, if the round-trip time is not known).

...
>	Requiring an RTT measurement means, of course, that QS requests
>may not be sendable with a SYN or SYN/ACK.  I would argue that that
>would have the pleasant side effect of not assigning router capacity to
>connections that are never established in the first place, at minimal
>performance cost.  This would also require a slight change to (1) in
>section 4.1.

I added the phrase "or soon after" to (1) in Section 4.1, so that
it now says the following:

 (1) At or soon after connection initiation, when the transport has
 no idea of the capacity of the network, as discussed above. `

But in some cases the sender does know at SYN or SYN/ACK time how much
data it wants to send.

...
>	In section 3.4: "It MUST NOT request a send rate in excess of
>the minimum allowable rate request that can encapsulate all of the
>available data."

Hmmm.  Section 3.4 is about what the *router* does.  I assume you mean
Section 4.6.1, "Determining the Rate to Request".

I revised the following sentence at the end of section 4.6.1:

 Therefore, it is recommended that the request for the initial sending
 rate be somewhat conservative, in order to improve the chances for
 more Quick-Start requests to be approved.

to the following:

 Following Section 4.1, the sender SHOULD NOT request a sending rate
 larger than it is able to use over the round-trip time of the
 connection (or over 100 ms, if the round-trip time is not known),
 except as required to round up the desired sending rate to the
 next-highest allowable request.

Mark and Pasi, does this seem fine to you?  For Quick-Start in
Experimental mode, while we are still learning how applications
will best be able to use Quick-Start?

- Sally

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 12 Sep 2005 21:59:24 +0300

> will best be able to use Quick-Start?

Yep, I'm fine with this, although I'm not sure if a given RTT default
helps much for calculations. Considering the wide range of possible RTTs
in today's networks of different kinds, 100 ms (or any other pre-defined
value) could be far off from the reality, in which case the calculated
request could be badly under- or oversized anyway. Implementations might
have some ways to make a better guess, for example using a cached
history of RTT measurements from earlier connections.

Thanks,
- Pasi