Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)
draft-ietf-tcpm-tcp-lcd-03

[Ballot comment]
Thank you for this work and for proposing it as Experimental.

My first Comment is very close to being a Discuss, and I hope you
feel able to add some text (perhaps to the Introduction) to give
the reader (and future generations) some guidance.

For experimental documents, I think it is important to give some
parameters of the nature of the experiment.
- What constraints will be placed on the experimental work to prevent
  the experiment spilling out into the Internet (walled garden)?
- What are the risks if the experiment is released?
  (perhaps a forward pointer to section 7)
- How will you judge whether the work is stable and successful?
- Do you have plans / proposals to return and revise the work for
  the Standards Track?

---

Section 2

Tiny nit, sorry

  This document improves TCP's behavior in case of "long connectivity
  disruptions".

Well, the document doesn't do that of itself :-)

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?


Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.  He
has personally reviewed this version and believes it is ready for
forwarding to the IESG for publication.



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


The document has had review in the TCPM working group, and underwent
several revisions (mainly prior to adoption as a WG document) based
on mailing list discussion and face-to-face presentations at meetings.
No feedback was received during working group last call, but it seems
that all of the original issues raised have been worked to closure
previously.  The shepherd has no concerns about the depth or breadth
of the reviews.  The evolution of the content is well-documented in
Appendix A of the draft.


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


No concerns.


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.


No concerns.



  (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 has been a reasonable amount of support & interest behind this in the
past, though the WGLC was quiet.  There have not been objections since it
was adopted as a working group document.



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


No.


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?



There is one outdated reference that would easily be fixed by the RFC Editor,
and the boilerplate is the 9/12/09 version rather than the 12/28/09 version.



  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].


The references are properly split.



  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?



The IANA Considerations are present.



  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?


Not Applicable.



  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.


From abstract:

  Disruptions in end-to-end path connectivity, which last longer than
  one retransmission timeout, cause suboptimal TCP performance.  The
  reason for this performance degradation is that TCP interprets
  segment loss induced by long connectivity disruptions as a sign of
  congestion, resulting in repeated retransmission timer backoffs.
  This, in turn, leads to a delayed detection of the re-establishment
  of the connection since TCP waits for the next retransmission timeout
  before it attempts a retransmission.

  This document proposes an algorithm to make TCP more robust to long
  connectivity disruptions (TCP-LCD).  It describes how standard ICMP
  messages can be exploited during timeout-based loss recovery to
  disambiguate true congestion loss from non-congestion loss caused by
  connectivity disruptions.  Moreover, a revert strategy of the
  retransmission timer is specified that enables a more prompt
  detection of whether or not the connectivity to a previously
  disconnected peer node has been restored.  TCP-LCD is a TCP sender-
  only modification that effectively improves TCP performance in case
  of connectivity disruptions.




    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

Nothing exceptional occurred during the working group process for this
document.


    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

There is an existing implementation in Linux, which was worked on by
the document authors.  This has been in the vanilla kernel since version
2.6.32 (for about a year) and always enabled.  Several Linux distributions
have shipped with this and no negative experiences have been reported that
were isolated to this mechanism.