Subject: [Tsvwg] Working Group Last Call for draft-ietf-tsvwg-quickstart-03.txt?

From: Sally Floyd <[email-masked]>
Date: Fri, 21 Apr 2006 17:35:45 -0700

We have just submitted a revised version of
draft-ietf-tsvwg-quickstart-03.txt.  We believe that this is now
ready for Working Group Last Call (finally!).

http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-03.txt
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-03.ps

- Sally

The changes, listed in the draft, are as following:

     Changes from draft-ietf-tsvwg-quickstart-02:

     * Some general editing.

     * Said that if the receiver receives a Quick-Start Request
       with a rate of zero, then the receiver SHOULD NOT send
       a Quick-Start response.  And that if the sender
       receives an acknowledgement of its packet with no
       Quick-Start response, then the sender MUST assume that the
       request was denied, and send a Report of Approved Rate
       with a rate of zero.

     * Said that if a Quick-Start packet is dropped or marked,
       the sender should not make more Quick-Start requests in this
       connection.

     * Said that the Quick-Start Request SHOULD be sent on a packet
       that requires an acknowledgement, e.g., a SYN, SYN/ACK, or data
       packet.

     * Made changes to the section on "TCP: A Quick-Start Request in the
       Middle of a Connection".

     * Added that if the TCP host is going to use the successful
       Quick-Start Request, it MUST start using it within one
       round-trip time of receiving the Quick-Start Response,
       or within three seconds, whichever is smaller.

     * Added a stronger applicability statement, in the abstract
       and in Section 10 on "Implementation and Deployment Issues".
       From feedback from the working group.

     * Added a section about MPLS.  From feedback from Mitchell
       Erblichs.

     * Strengthened the language of the difficulties presented by
       multi-access links.

     * Added a discussion in Section 10.3 about the deployment of
       Quick-Start on single-hop paths.  From feedback from
       Mitchell Erblichs.

     * Clarified that the "router" function of approving
       Quick-Start requests includes the IP-layer processing
       at the sender.

     * Clarified in Section 3.3 on "Processing the Quick-Start
       Request at Routers" that this document standardizes only
       the semantics of Quick-Start, and not the specific
       algorithms for processing Quick-Start requests at routers.

     * Clarified in Section 3.3 on "Processing the Quick-Start
       Request at Routers" that a router will have to consider
       the previous Quick-Start requests in approving a new one.

     * In Section 9.3 on "Quick-Start with QoS-enabled Traffic",
       which says that routers are free to take into account
       the diff-serv codepoint in considering QS requests, clarified
       that routers are also free to take into account their own
       understanding of priorities.

     * Added the Temporary bit to Appendix D on "Possible Additional
       Uses for the Quick-Start Option".  Clarified that the Quick-Start
       mechanism is not designed to help routers achieve full link
       utilization.

     * Editing from feedback from Gorry Fairhurst.

---

From: Erblichs <[email-masked]>
Date: Mon, 24 Apr 2006 09:59:36 -0700

Sally Floyd, Mark Allman, et al,

	If clarification is requested, I will offer a
	followup email.

	Given our past discussions and some additional
	thinking about your concern for 
	slow speed (wireless/ GPRS (Generalized Packet Radio
	Service) / etc, support the following suggestion
	is offered.

	Reference RFC 3150 : E2E Perf Implication of Slow Links

	The suggestion is a DS (Downward Scale bit) against the
	specified bps scale. This should allow a finer spacing
	of bps bits for the higher speed links and still allow
	the support for slower speed links. The scale should
	use shift operation to minimze the overhead.

	The bit is overloaded in that it SHOULD also indicate
	that:

	-- The timeout for the initial request to establish a TCP
           connection should be upwardly scaled.
           Reason : Ludwig, A multi-layer Tracing of TCP over a Reliable
	   Wireless Link, ACM Sigmetrics 1999 -- publicly indicates that 
           this is a issue to establish a number of low speed
connections.

	-- 3150: Due to the low bps scaled rate, the number of MTU sized
	   pkts is minimal. Section 2.3 Choosing MTU sizes of 3150 should
           be consulted. This would also allow a larger number of
	   pkts to be initially placed on the wire, decrease queueing
	   delays, etc..

	-- Due to the low speed environment, the coarse timeout should
	   be upwardly scaled to 30 secs.

        -- Lastly, which is probably the most controverisal, upon
percieved
	   dropouts the standard TCP MD should be scaled back (if implimented
	   at all) because LOSS in wireless / slow links are NOT an indication
	   of congestion.

	Mitchell Erblich
	------------------

---

From: Mark Allman <[email-masked]>
Date: Mon, 24 Apr 2006 22:46:22 -0400

> 	   at all) because LOSS in wireless / slow links are NOT an indication

First, I disagree that it would ever be prudent engineering to use a
single bit to indicate everything in this disparate list.  Ever.

Second, about the notion of a finer-grained rate request...

  + I understand that you believe in the need for finer grainer rate
    requests.  That's fine.

  + In discussions with various authors of this document, you have not
    compelled us that a change in this area is needed.

  + I have not seen this idea get a bunch of traction on the tsvwg
    mailing list.

  + This document has been around for awhile and has received detailed
    review from many folks.  As far as I can recall, this issue has
    never come up in a big way.

  + Therefore, it seems to me that the current document represents
    consensus (which does not mean everyone agrees).

  + And, further, if that read is wrong and there are folks who think we
    need finer-grained requests then those folk ought to speak up now.
    We will clearly follow the consensus of the group.

Maybe the chairs have some wisdom to add here, but I think your point is
taken and we need to see input from others.

allman

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 24 Apr 2006 22:57:54 -0500

>taken and we need to see input from others.

"rough consensus" is just that: "rough"

I too have not seen these points gain any traction, so far.

I have been on the minority side of a point many times, and had to agree to 
disagree, and move on.

Barring any others having strong differing beliefs they wish to express 
here, I believe TSVWG will move forward with the rough consensus model here.

>allman

Cheers,
James
IETF TSVWG co-chair

              ***********************************
     "It should NEVER be inconvenient to do the right thing"

---

From: Erblichs <[email-masked]>
Date: Tue, 25 Apr 2006 10:34:13 -0700

Mark Allman, et al,

	FYI, 

	The bit suggestion is really to indicate that the EXPECTATION is a
	slow-speed / wireless environment and thus the 3150 RFC Slow-speed Best
	Common Practices doc, et al should be considered with this
	connection.

	Their were very strong reasons to support the lower N values.

	Thus, if the doc is respun, CAN I suggest that a reference to 
	the 3150 RFC be made if the request is with low N values.

	Mitchell Erblich
	-----------------------------

Mark Allman wrote:
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature