Subject: [Tsvwg] draft-ietf-tsvwg-quickstart-02.txt

From: Sally Floyd <[email-masked]>
Date: Wed, 08 Mar 2006 13:09:30 -0800

We have revised draft-ietf-tsvwg-quickstart-02.txt, in response to
feedback from the last IETF and the mailing list, and we think
that we are finally finised with revisions and are ready for this to
advance to Experimental.

The new version of the draft is available at:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-quickstart-02.txt

The main substantive change is the change of the "Report of Approved
Rate" option from a "Possible Use" listed in Appendix D to a required
use.  The "Report of Approved Rate" allows routers and receivers
some protection against misbehaving senders, and allows greater
accuracy in accounting for promised Quick-Start bandwidth for those
routers that care to maintain per-flow state.

Along with this change, we changed the four-bit "Reserved" field
to a "Function" field, and rearranged some of the fields in the
Quick-Start option so that the Function field comes before
subsidiary fields. 

We also added an Appendix E discussing some of the comments
raised in Bob Briscoe's internet-draft on Quick-Start, and made
most of the revisions that he suggested in the second half
of his document.

The changes are listed below.  Feedback would be appreciateed.
I think that this version of the draft is ready to move on to
the next step of the standards track towards Experimental.

- Sally
http://www.icir.org/floyd/

-----------------------------------------------------------------
     Changes from draft-ietf-tsvwg-quickstart-01:
     * Added a citation to SPAND: Speeding Up Short Data Transfers.
     * Added a sentence in Section 8.1 on "Implementation Issues for
       Processing Quick-Start Requests" about multi-access links.
     * Mentioned the IP Router Alert option, RFC 2113, in Appendix
       A.1.1.
     * Added a discussion of lower-than-best-effort service.
     * Added a few sentences about the requirements for
       randomness in the nonce.
     * Changed the name of the option from the Quick-Start Request
       Option to the Quick-Start Option.
     * Changed the semantics of the Reserved field to the Function
       field, adding that a Quick-Start option is only interpreted
       as a request if this field is zero.
     * Changed the "Reporting Approved Rate" option from a
       "Possible Use" in Appendix D to a required use in Section 3.1,
       to allow routers and receivers some protection against
       misbehaving senders.
     * Changes from feedback from Bob Briscoe:
       - Added Appendix E with a response to Sections 1-3 of
         Bob Briscoe's document.
       - Added a clarification that the approval of a
         Quick-Start request at a router does not affect
         the treatment of the subsequent arriving
         Quick-Start data packets.
       - Added the one-way hash function as an alternate
         implementation for the QS Nonce.
       - Clarified the phrase "incrementally deployable", adding
         the following:
         "We note that while Quick-Start is incrementally deployable
         in this sense, a Quick-Start request can not be approved
         for a particular connection unless both end-nodes and all
         of the routers along the path have been configured to
         support Quick-Start."
       - Clarified semantics about additional rate.
       - Said that when denying a rate request, the router
         may in the future use the QS Nonce field to report
         an error code.
       - Add Bob's suggestion from Section 4.4 as an alternate
         possible rate encoding.
       - Made changes suggested in Section 5.1.3 of Bob's paper,
         including saying that the router should decrement the QS TTL
         by the same amount that it decrements the IP TTL (on the
         off chance that it decrements the IP TTL by more than one).
       - Fixed nits.

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