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

From: "Duke, Martin" <[email-masked]>
Date: Thu, 8 Sep 2005 11:07:46 -0700

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.

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.

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

Martin

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