Quick-Start for TCP and IP
draft-ietf-tsvwg-quickstart-07

[Ballot comment]
This is a very interesting and great spec.
But I still worry about the practical tradeoff
for early deployers implied by the experimental
results:

    Measurement studies of interactions between transport protocols and
    middleboxes [MAF04] show that for 70% of the web servers
    investigated, no connection is established if the TCP SYN packet
    contains an unknown IP option  ...
    If the TCP sender doesn't receive a response to the SYN or SYN/ACK
    packet containing the Quick-Start Request, then the TCP sender
    SHOULD resend the SYN or SYN/ACK packet without the Quick-Start
    ...

And the cost evaluation in Section 9.2 does not take this
into account at all, as far as I can see.

[Ballot comment]
If the tunnel ingress for the simple tunnel is at a router, the IP
    TTL of the inner header is generally decremented during forwarding
    before tunnel encapsulation takes place.

This is not true for L2TP tunnels, though I understand that the document is not making any specific claim about L2TP at this time. For IPinIP and GRE tunnels, the TTL is decremented on ingress and egress for each tunnel. For L2TP, it is only decremented at an LNS, which is typically the egress of the tunnel.

[Ballot discuss]
Regarding this statement:

    If the tunnel ingress for the simple tunnel is at a router, the IP
    TTL of the inner header is generally decremented during forwarding
    before tunnel encapsulation takes place.

I don't believe this is entirely accurate. In cisco IOS, TTL decrement on the inner packet is generally done on egress from the tunnel, not ingress before the tunnel encapsulation takes place.

IANA Last Call Comment:

Upon approival of this document IANA will take three actions: registration of an
IPv4 Option Number, registration of an IPv6 Option Number and registration of a
TCP Option.

For the IPv4 Option Number, IANA will add the following registration to
http://www.iana.org/assignments/ip-parameters

Copy Class Number Value Name
---- ----- ------ ----- ----
0 00 TBD1 TBD2 QS - Quick-Start

For the IPv6 Option Number, IANA will add the following registration to
http://www.iana.org/assignments/ipv6-parameters

HEX act chg rest
--- --- --- -----
TBD3 00 1 TBD4 Quick-Start

For the TCP Option, IANA will add the following registration to
http://www.iana.org/assignments/tcp-parameters

Kind Length Meaning
---- ------ ------------------------------
TBD5 8 Quick-Start Response

We understand these to be the only IANA Actions for this document.

PROTO Write-up

    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

Yes, Shepherd is James Polk (jmpolk@cisco.com)

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Yes. There are no concerns wrt the reviews made.

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No, I do not.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No, the ADs have been aware of this document's reviews over the past 2 months, and have stated their satisfaction.

    1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is solid WG consensus backing this document moving forward.  There have been many from the WG involved in the review of this document, and all appear satisfied this is a solid document.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

  No, there are no threats of appeals that I'm aware of.

    1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes.  There are no nits, no miscellaneous warnings, no experimental warnings in the current version (-05).

    1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?  The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publication).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?  Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

The references are split. There are 8 normative references, all to RFCs.

    1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

This document defines an optional means of accelerating normal slow
start(ish) transfer rate procedures of a transport protocol into the (potentially many) Mbps flows have access to.  The Quickstart sending rate is requested, and never mandatory.  The fall back is to normal slow
start(ish) ramp ups, requiring many RTTs,  in bandwidth utilized.  This document outlines how Quickstart is used in TCP, but the mechanism is not specific to any transport protocol - with a lot of discussion on how it affects UDP (VoIP) flows.  This document limits flows that can use Quickstart to at least 80kbps or higher.  There are pitfalls and problems to be explored with this mechanism (most thought of are discussed extensively), which is why this is Experimental, instead of Standards Track. Rough running code of this mechanism already exists in several places, with generally positive results, even for VoIP.

        *    Working Group Summary

There is strong consensus in the WG to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed.

        *    Protocol Quality

This document is making an experimental, optional extension to transport protocol initial transfer rates. TCP is highlighted in the document, though other transport protocols are able to use this mechanism. It is not making a new protocol.

This document has been well reviewed in the WG and comments raised have been addressed promptly.