Re: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status

Disclaimer: Chair hat off

I have read draft-touch-tcpm-2140bis-06. I believe that this document is a good starting point for a new TCPM working group item targeting an informational RFC.

Below are some initial comments that are hopefully not difficult to sort out in a follow-up version.

Comments:

- The abstract and/or the introduction could better explain the purpose of the document and why it is informational. For instance, a sentence such as "this document provides informational guidance to TCP implementers..." or the like could be useful.

- While this may be somewhat obvious to most of us, the document could also mention more explicitly that the content does not affect TCP interoperability.

- Section 2 may not be required given that the document does not use RFC 2119 language, except in a quote from RFC 7413 and in the appendix that will be removed prior to publication. If section 2 stays in the document, it should be reworded according to RFC 8174.

- In Section 6, I find the sentence and references "RTT values are updated by a more complicated mechanism [RFC1644][Ja86]" somewhat confusing. First, I don't know what [Ja86] actually refers to; without a public archive such a reference has only very limited value to (younger) readers. That also applies to a later use of [Ja86]. Second, RFC 1644 is now obsolete and I think T/TCP belongs better into Appendix A. I wonder if this section could be reworded with references to RFC 6298? The same comment may also apply to later discussions of the RTT.

Editorial nits:

- The abstract may be more useful on the first page

- Section 8: "TCP is sometimes used in situations where packets of the same host-pair always take the same path." This sentence seems broken, no?

- Section 8: "some Virtual Private Networks (VPNs) are known to use proprietary UDP encapsulation methods". I don't understand why "proprietary" is used in this context; actually I even don't even understand why "UDP encapsulation" matters. Doesn't this paragraph apply to all tunnel encaps?

- Section 9: "One such problem is determining the associated prior outgoing packet for an incoming packet, to infer RTT from the exchange." Well, as a non-native speaker, I had to read this sentence at least three times to understand what is probably meant by that.

Thanks

Michael

> -----Original Message-----
> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael
> Sent: Wednesday, March 6, 2019 11:48 PM
> To: tcpm@ietf.org
> Subject: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06
> targeting informational status
> 
> Hi all,
> 
> The document draft-touch-tcpm-2140bis has been discussed quite a bit in
> TCPM. One question has been the status (BCP or INFO). The version
> draft-touch-tcpm-2140bis-06 explicitly targets informational status and
> plans to obsolete RFC 2140 (which is informational, too).
> 
> The intention of this e-mail is to confirm that draft-touch-tcpm-
> 2140bis-06 should be adopted as informational TCPM working group item,
> i.e., that a new item should be added to the TCPM charter:
> 
>   Nov. 2019  Submit document on TCP Control Block Interdependence to
> the IESG for publication as Informational RFC
> 
> The adoption call runs on the TCPM mailing list until March 22. Please
> let us know if you support adoption of the document, or if there are
> any concerns.
> 
> Best regards
> 
> Michael
> (TCPM co-chair)
> 
> 
> -------- Forwarded Message --------
> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Friday, January 4, 2019 5:52 PM
> To: tcpm@ietf.org
> Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-
> 2140bis-06.txt
> 
> FYI -
> This version:
>     - obsoletes 2140
>     - says so in the abstract and intro
>     - includes a "changes from 2140" section summarizing the
> differences
> Note that the earlier versions did cite 2140, but did not as directly
> indicate that this is intended as its replacement.
> Joe
> 
> -------- Forwarded Message --------
> Subject:
> New Version Notification for draft-touch-tcpm-2140bis-06.txt
> Date:
> Fri, 04 Jan 2019 08:49:25 -0800
> From:
> internet-drafts@ietf.org
> To:
> Safiqul Islam <safiquli@ifi.uio.no>, Michael Welzl
> <michawe@ifi.uio.no>, Joseph Touch <touch@strayalpha.com>, Joe Touch
> <touch@strayalpha.com>
> 
> 
> 
> A new version of I-D, draft-touch-tcpm-2140bis-06.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.
> 
> Name: draft-touch-tcpm-2140bis
> Revision: 06
> Title: TCP Control Block Interdependence
> Document date: 2019-01-04
> Group: Individual Submission
> Pages: 22
> URL: https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-
> 06.txt
> Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/
> Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-2140bis-06
> Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tcpm-
> 2140bis
> Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-2140bis-06
> 
> Abstract:
> This memo updates and replaces RFC 2140's description of
> interdependent TCP control blocks, in which part of the TCP state is
> shared among similar concurrent or consecutive connections. TCP
> state includes a combination of parameters, such as connection
> state, current round-trip time estimates, congestion control
> information, and process information. Most of this state is
> maintained on a per-connection basis in the TCP Control Block (TCB),
> but implementations can (and do) share certain TCB information
> across connections to the same host. Such sharing is intended to
> improve overall transient transport performance, while maintaining
> backward-compatibility with existing implementations. The sharing
> described herein is limited to only the TCB initialization and so
> has no effect on the long-term behavior of TCP after a connection
> has been established.
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm