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 :-)quot; (type) Header Parameter is used by JWS applications to
  declare the MIME Media Type [IANA.MediaTypes] of this complete JWS.
  This is intended for use by the application when more than one kind
  of object could be present in an application data structure that can
  contain a JWS; the application can use this value to disambiguate
  among the different kinds of objects that might be present.  It will
  typically not be used by applications when the kind of object is
  already known.  This parameter is ignored by JWS implementations; any
  processing of this parameter is performed by the JWS application.
  Use of this Header Parameter is OPTIONAL.

  Per RFC 2045 [RFC2045], all media type values, subtype values, and
  parameter names are case-insensitive.  However, parameter values are
  case-sensitive unless otherwise specified for the specific parameter.

  To keep messages compact in common situations, it is RECOMMENDED that
  producers omit an "application/" prefix of a media type value in a
  "typ" Header Parameter when no other '/' appears in the media type
  value.  A recipient using the media type value MUST treat it as if
  "application/" were prepended to any "typ" value not containing a
  '/'.  For instance, a "typ" value of "example" SHOULD be used to
  represent the "application/example" media type; whereas, the media
  type "application/example;part="1/2"" cannot be shortened to
  "example;part="1/2"".

  The "typ" value "JOSE" can be used by applications to indicate that
  this object is a JWS or JWE using the JWS Compact Serialization or

Jones, et al.            Expires July 3, 2015                [Page 13]
Internet-Draft          JSON Web Signature (JWS)          December 2014

  the JWE Compact Serialization.  The "typ" value "JOSE+JSON" can be
  used by applications to indicate that this object is a JWS or JWE
  using the JWS JSON Serialization or the JWE JSON Serialization.
  Other type values can also be used by applications.

4.1.10.  "cty" (Content Type) Header Parameter

  The "cty" (content type) Header Parameter is used by JWS applications
  to declare the MIME Media Type [IANA.MediaTypes] of the secured
  content (the payload).  This is intended for use by the application
  when more than one kind of object could be present in the JWS
  payload; the application can use this value to disambiguate among the
  different kinds of objects that might be present.  It will typically
  not be used by applications when the kind of object is already known.
  This parameter is ignored by JWS implementations; any processing of
  this parameter is performed by the JWS application.  Use of this
  Header Parameter is OPTIONAL.

  Per RFC 2045 [RFC2045], all media type values, subtype values, and
  parameter names are case-insensitive.  However, parameter values are
  case-sensitive unless otherwise specified for the specific parameter.

  To keep messages compact in common situations, it is RECOMMENDED that
  producers omit an "application/" prefix of a media type value in a
  "cty" Header Parameter when no other '/' appears in the media type
  value.  A recipient using the media type value MUST treat it as if
  "application/" were prepended to any "cty" value not containing a
  '/'.  For instance, a "cty" value of "example" SHOULD be used to
  represent the "application/example" media type; whereas, the media
  type "application/example;part="1/2"" cannot be shortened to
  "example;part="1/2"".

4.1.11.  "crit" (Critical) Header Parameter

  The "crit" (critical) Header Parameter indicates that extensions to
  the initial RFC versions of [[ this specification ]] and [JWA] are
  being used that MUST be understood and processed.  Its value is an
  array listing the Header Parameter names present in the JOSE Header
  that use those extensions.  If any of the listed extension Header
  Parameters are not understood and supported by the recipient, it MUST
  reject the JWS.  Producers MUST NOT include Header Parameter names
  defined by the initial RFC versions of [[ this specification ]] or
  [JWA] for use with JWS, duplicate names, or names that do not occur
  as Header Parameter names within the JOSE Header in the "crit" list.
  Producers MUST NOT use the empty list "[]" as the "crit" value.
  Recipients MAY reject the JWS if the critical list contains any
  Header Parameter names defined by the initial RFC versions of [[ this
  specification ]] or [JWA] for use with JWS, or any other constraints

Jones, et al.            Expires July 3, 2015                [Page 14]
Internet-Draft          JSON Web Signature (JWS)          December 2014

  on its use are violated.  When used, this Header Parameter MUST be
  integrity protected; therefore, it MUST occur only within the JWS
  Protected Header.  Use of this Header Parameter is OPTIONAL.  This
  Header Parameter MUST be understood and processed by implementations.

  An example use, along with a hypothetical "exp" (expiration-time)
  field is:

    {"alg":"ES256",
      "crit":["exp"],
      "exp":1363284000
    }

4.2.  Public Header Parameter Names

  Additional Header Parameter names can be defined by those using JWSs.
  However, in order to prevent collisions, any new Header Parameter
  name should either be registered in the IANA JSON Web Signature and
  Encryption Header Parameters registry defined in Section 9.1 or be a
  Public Name: a value that contains a Collision-Resistant Name.  In
  each case, the definer of the name or value needs to take reasonable
  precautions to make sure they are in control of the part of the
  namespace they use to define the Header Parameter name.

  New Header Parameters should be introduced sparingly, as they can
  result in non-interoperable JWSs.

4.3.  Private Header Parameter Names

  A producer and consumer of a JWS may agree to use Header Parameter
  names that are Private Names: names that are not Registered Header
  Parameter names Section 4.1 or Public Header Parameter names
  Section 4.2.  Unlike Public Header Parameter names, Private Header
  Parameter names are subject to collision and should be used with
  caution.

5.  Producing and Consuming JWSs

5.1.  Message Signature or MAC Computation

  To create a JWS, the following steps are performed.  The order of the
  steps is not significant in cases where there are no dependencies
  between the inputs and outputs of the steps.

  1.  Create the content to be used as the JWS Payload.

Jones, et al.            Expires July 3, 2015                [Page 15]
Internet-Draft          JSON Web Signature (JWS)          December 2014

  2.  Compute the encoded payload value BASE64URL(JWS Payload).

  3.  Create the JSON object(s) containing the desired set of Header
      Parameters, which together comprise the JOSE Header: if the JWS
      Compact Serialization is being used, the JWS Protected Header, or
      if the JWS JSON Serialization is being used, the JWS Protected
      Header and/or the JWS Unprotected Header.

  4.  Compute the encoded header value BASE64URL(UTF8(JWS Protected
      Header)).  If the JWS Protected Header is not present (which can
      only happen when using the JWS JSON Serialization and no
      "protected" member is present), let this value be the empty
      string.

  5.  Compute the JWS Signature in the manner defined for the
      particular algorithm being used over the JWS Signing Input
      ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
      BASE64URL(JWS Payload)).  The "alg" (algorithm) Header Parameter
      MUST be present in the JOSE Header, with the algorithm value
      accurately representing the algorithm used to construct the JWS
      Signature.

  6.  Compute the encoded signature value BASE64URL(JWS Signature).

  7.  If the JWS JSON Serialization is being used, repeat this process
      (steps 3-6) for each digital signature or MAC operation being
      performed.

  8.  Create the desired serialized output.  The JWS Compact
      Serialization of this result is BASE64URL(UTF8(JWS Protected
      Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS
      Signature).  The JWS JSON Serialization is described in
      Section 7.2.

5.2.  Message Signature or MAC Validation

  When validating a JWS, the following steps are performed.  The order
  of the steps is not significant in cases where there are no
  dependencies between the inputs and outputs of the steps.  If any of
  the listed steps fails, then the signature or MAC cannot be
  validated.

  When there are multiple JWS Signature values, it is an application
  decision which of the JWS Signature values must successfully validate
  for the JWS to be accepted.  In some cases, all must successfully
  validate or the JWS will be considered invalid.  In other cases, only
  a specific JWS Signature value needs to be successfully validated.
  However, in all cases, at least one JWS Signature value MUST

Jones, et al.            Expires July 3, 2015                [Page 16]
Internet-Draft          JSON Web Signature (JWS)          December 2014

  successfully validate or the JWS MUST be considered invalid.

  1.  Parse the JWS representation to extract the serialized values
        for the components of the JWS.  When using the JWS Compact
        Serialization, these components are the base64url encoded
        representations of the JWS Protected Header, the JWS Payload,
        and the JWS Signature, and when using the JWS JSON
        Serialization, these components also include the unencoded JWS
        Unprotected Header value.  When using the JWS Compact
        Serialization, the JWS Protected Header, the JWS Payload, and
        the JWS Signature are represented as base64url encoded values in
        that order, with each value being separated from the next by a
        single period ('.') character, resulting in exactly two
        delimiting period characters being used.  The JWS JSON
        Serialization is described in Section 7.2.

  2.  Base64url decode the encoded representation of the JWS Protected
        Header, following the restriction that no line breaks, white
        space, or other additional characters have been used.

  3.  Verify that the resulting octet sequence is a UTF-8 encoded
        representation of a completely valid JSON object conforming to
        RFC 7159 [RFC7159]; let the JWS Protected Header be this JSON
        object.

  4.  If using the JWS Compact Serialization, let the JOSE Header be
        the JWS Protected Header.  Otherwise, when using the JWS JSON
        Serialization, let the JOSE Header be the union of the members
        of the corresponding JWS Protected Header and JWS Unprotected
        Header, all of which must be completely valid JSON objects.
        During this step, verify that the resulting JOSE Header does not
        contain duplicate Header Parameter names.  When using the JWS
        JSON Serialization, this restriction includes that the same
        Header Parameter name also MUST NOT occur in distinct JSON
        object values that together comprise the JOSE Header.

  5.  Verify that the implementation understands and can process all
        fields that it is required to support, whether required by this
        specification, by the algorithm being used, or by the "crit"
        Header Parameter value, and that the values of those parameters
        are also understood and supported.

  6.  Base64url decode the encoded representation of the JWS Payload,
        following the restriction that no line breaks, white space, or
        other additional characters have been used.

  7.  Base64url decode the encoded representation of the JWS
        Signature, following the restriction that no line breaks, white

Jones, et al.            Expires July 3, 2015                [Page 17]
Internet-Draft          JSON Web Signature (JWS)          December 2014

        space, or other additional characters have been used.

  8.  Validate the JWS Signature against the JWS Signing Input
        ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
        BASE64URL(JWS Payload)) in the manner defined for the algorithm
        being used, which MUST be accurately represented by the value of
        the "alg" (algorithm) Header Parameter, which MUST be present.
        See Section 10.6 for security considerations on algorithm
        validation.  Record whether the validation succeeded or not.

  9.  If the JWS JSON Serialization is being used, repeat this process
        (steps 4-8) for each digital signature or MAC value contained in
        the representation.

  10.  If none of the validations in step 9 succeeded, then the JWS
        MUST be considered invalid.  Otherwise, in the JWS JSON
        Serialization case, return a result to the application
        indicating which of the validations succeeded and failed.  In
        the JWS Compact Serialization case, the result can simply
        indicate whether or not the JWS was successfully validated.

  Finally, note that it is an application decision which algorithms may
  be used in a given context.  Even if a JWS can be successfully
  validated, unless the algorithm(s) used in the JWS are acceptable to
  the application, it SHOULD consider the JWS to be invalid.

5.3.  String Comparison Rules

  Processing a JWS inevitably requires comparing known strings to
  members and values in JSON objects.  For example, in checking what
  the algorithm is, the Unicode string "alg" will be checked against
  the member names in the JOSE Header to see if there is a matching
  Header Parameter name.  The same process is then used to determine if
  the value of the "alg" Header Parameter represents a supported
  algorithm.

  The JSON rules for doing member name comparison are described in
  Section 8.3 of RFC 7159 [RFC7159].  Since the only string comparison
  operations that are performed are equality and inequality, the same
  rules can be used for comparing both member names and member values
  against known strings.

  These comparison rules MUST be used for all JSON string comparisons
  except in cases where the definition of the member explicitly calls
  out that a different comparison rule is to be used for that member
  value.  Only the "typ" and "cty" member values defined in this
  specification do not use these comparison rules.

Jones, et al.            Expires July 3, 2015                [Page 18]

  (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.