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

Joe Touch <> Mon, 15 April 2019 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 348D51201A9; Mon, 15 Apr 2019 06:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5r7Wf_xMiiNM; Mon, 15 Apr 2019 06:39:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A8E91201A1; Mon, 15 Apr 2019 06:39:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BUat4ybNL1+3dXoiMt50ik7wfN1oAY+hb9u+kpwjjO4=; b=rP07y/WichjnVoxVYHAcougwE vXIxUJD4/hBUJYrhDq7OCBYUmlISlXHAWqgkKl7SzDtjq+i3HKIwq4ky8NXPrQ5mjhUxFZfHrFln0 NGtTXnUsfuJQ0kYHRpKdGhnG/acOOaJ2UQ3IkA4gtXTqyPm53Sl+57tfEhikS2ATUwZRjOXQZxr+F x/sM4HE9IrYArn7j8WZccwyhbkN7dN9TR7T2fIWmdB/U/aesDI5fWOFTqyhzIvD3anYrt2KIMDiyO XYNpVYXNr33vVkAe6wWmnzuewGBj7CkwDces6BV9kPmFC9Wrmxo+sjeJX6gIUZRZ2AXheyl6si5x+ 8cIQpBNDQ==;
Received: from ([]:52302 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1hG1pK-003eF3-Ot; Mon, 15 Apr 2019 09:39:19 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail-3FAD1B30-5B3B-4DF5-A7AE-34431AE8C089"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
X-Apple-Base-Url: x-msg://2/
X-Universally-Unique-Identifier: 8BE81A72-A10F-407D-824F-EEDEB9790FD6
X-Apple-Mail-Remote-Attachments: YES
From: Joe Touch <>
X-Mailer: iPad Mail (16E227)
In-Reply-To: <>
X-Apple-Windows-Friendly: 1
Date: Mon, 15 Apr 2019 06:39:14 -0700
Cc: "" <>, "" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: "Scharf, Michael" <>
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2019 13:39:24 -0000

Hi, Michael,

I am in the process of posting the new draft-ietf-tcp-2140bis-00 version, which addresses your comments as indicated below.


> On Mar 11, 2019, at 2:56 PM, Scharf, Michael <> wrote:
> 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.

Done in the abstract and intro.

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

The section is revised to explain that those keywords do not have special meaning, which I think is needed to be clear.

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

Agreed and removed throughout.

> Second, RFC 1644 is now obsolete and I think T/TCP belongs better into Appendix A.

Agreed; we thought we removed all but the one pointer to the appendix, and now have.

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

In some cases in some places, but I think you mean RFC6928.

> Editorial nits:
> - The abstract may be more useful on the first page

We have no control over this; the boilerplate for drafts is included as required. This would be corrected upon final publication by the RFC Editor as possible anyway.

> - 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?

Yes, and reversed. It has been revised for clarity.

> - 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?

Yes; also revised for clarity. The issue, FWIW, is to differentiate encapsulation from encryption; the former remains problematic if the encapsulation uses non-standard mechanisms that cannot be readily determined in advance using known protocols.

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

Also revised for clarity as well.

> Thanks
> Michael
>> -----Original Message-----
>> From: tcpm [] On Behalf Of Scharf, Michael
>> Sent: Wednesday, March 6, 2019 11:48 PM
>> To:
>> 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 [] On Behalf Of Joe Touch
>> Sent: Friday, January 4, 2019 5:52 PM
>> To:
>> 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:
>> To:
>> Safiqul Islam <>, Michael Welzl
>> <>, Joseph Touch <>, Joe Touch
>> <>
>> 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:
>> 06.txt
>> Status:
>> Htmlized:
>> Htmlized:
>> 2140bis
>> Diff:
>> 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
>> The IETF Secretariat
>> _______________________________________________
>> tcpm mailing list
> _______________________________________________
> tcpm mailing list