Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08

<> Thu, 27 June 2019 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23AF812013D; Thu, 27 Jun 2019 08:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8tV81kdU4QFl; Thu, 27 Jun 2019 08:58:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A0BC12004D; Thu, 27 Jun 2019 08:58:04 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 27 Jun 2019 16:58:02 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Jun 2019 16:58:02 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 27 Jun 2019 16:58:02 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 27 Jun 2019 16:57:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+/ejBaX16GdV/WLC7roFWwFZQbPu0GM+sWbr9gYqT0=; b=XqSykpvONtChtR1R/pqvB4Y1v35pB6qE+1GgNUzwTwqqi1psPLCAsN3ggTCDKZHynNpt7UxITJB2Arn05zD5fdQ2pthfoymStKrGBZwF05XOhi9Dbdouz4Ylb0pIZRDp2k0cRl5IW9gpWv3FooEZNaPjk/0D+NtbW9NR2+3Qbd0=
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ( by LNXP123MB1994.GBRP123.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 15:58:01 +0000
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2008.014; Thu, 27 Jun 2019 15:58:01 +0000
Thread-Topic: WGLC for draft-ietf-tcpm-converters-08
Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDw
Date: Thu, 27 Jun 2019 15:58:01 +0000
Message-ID: <LNXP123MB258781EFAC897351EDB153E2EBFD0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6813bf8d-6032-4677-41d5-08d6fb183b51
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1994;
x-ms-traffictypediagnostic: LNXP123MB1994:
x-ms-exchange-purlcount: 2
x-antispam-2: 1
x-microsoft-antispam-prvs: <LNXP123MB19941523D6FB5C295CEB665FEBFD0@LNXP123MB1994.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 008184426E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(376002)(346002)(366004)(136003)(39860400002)(13464003)(53754006)(189003)(199004)(54534003)(305945005)(99286004)(7736002)(2906002)(6246003)(14444005)(11346002)(486006)(256004)(476003)(8676002)(966005)(14454004)(55016002)(316002)(64756008)(52536014)(68736007)(6116002)(3846002)(4326008)(446003)(478600001)(5660300002)(66556008)(25786009)(110136005)(9686003)(6306002)(73956011)(66446008)(66476007)(66946007)(74316002)(53936002)(6436002)(6506007)(26005)(66574012)(76176011)(66066001)(81156014)(229853002)(8936002)(102836004)(71200400001)(7696005)(53546011)(186003)(71190400001)(81166006)(86362001)(33656002)(76116006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1994; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: YnAMjQ4Ohj43DWN30mEPDW14e2agGRsliDfJaEyvSQJrMcH6P7n2uthbQdsFL1qaJqOB7A9mQRPhDJsiXOzDzuTSs3kd7dPdhTEmHgf0g/mT+ZNe//91Pe7J9F4Gc9bxhSe97ax9mrInUxJzwjoHVrKfhxkxCC01e1bSHJHxuR9Vjz3sb0fMydFlm/eWWLCKgVeSzzKHjAq37QJtzy0wGK9kLp8S03aoVFyTnY4tSIYW3NfMD5fDQwBjHJMw2eK2IWOiRKmdnuRN16Kk+sdhGkL6djY/swBrZ2ooV93j7PHjFKHnrYzt//sWGtJhPo72wei1FPxjnTFA8eAT0FalXZDpufqiZGV5VWVcRjXqZZpQpPw60A2ueK/L88GpcHNu9uOerzE2p4Us50xxr+uCGltC21UiMRZY4/ga60JZ7b4=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6813bf8d-6032-4677-41d5-08d6fb183b51
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 15:58:01.1662 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1994
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6578
X-NAI-Spam-Version: : core <6578> : inlines <7111> : streams <1825718> : uri <2860983>
Archived-At: <>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
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: Thu, 27 Jun 2019 15:58:09 -0000

I support this document. Thanks to the authors for the nice work. 

Here are some comments /questions and suggested clarifications.

Section 4.1
"    The Client and the Transport Converter MUST send the fixed-sized
   header, shown in Figure 9, as the first four bytes of the bytestream."
Are there any other protocols that claim rights on the first bytes of the bytestream? Even in the context of signalling as indicated by the port# (to be assigned), is this certain?

" Data added by the Convert protocol to the TCP bytestream in the
   upstream connection is unambiguously distinguished from payload data
   in the downstream connection by the Total Length field in the Convert
Is it required that the Convert data is at a fixed point in the bytestream? Think you've assumed it's at the start?
(Also, I think you could delete 'upstream' and 'downstream' in the quoted sentence - in any case, presumably they should both be one or the other)

Convert protocol:
How do the messages with the Supported TCP Extensions TLV and Connect TLV relate to each other? Is it required to learn through the "Supported TCP Extensions" that a Converter supports a particular TCP option before sending a Connect with that Option? I assume not - and that it's just a MAY to send the Supported TCP Extensions - as it seems to me like an optimisation and not too much harm happens if you send a Connect for an unsupported extension. 

Suggested clarifications - significant:-

I think it would be great if Section 3 was expanded into a "protocol model" in particular to expand on
<<   2. What messages are being transmitted and what do they mean?>> - figures show the basic msg exchanges (info, connect, extended, supported, cookie and error)
<<   3. What are the important, but unobvious, features of the protocol?>> eg use of assigned port# ; use of first bytes of bytestream ;etc.

I think you could distinguish more carefully between: the initiator of the TCP convert protocol and the other 'legacy' end point versus the end device downstream on a broadband line and the server upstream in the internet. The language of the doc basically assumes that a "Client" fulfils both the first roles and a "Server" fulfils both the last roles, but this needs not always be the case. I realised this reading Section 4.2.8, but I suspect it's true in many other places. 

Suggested clarifications - other:-
Section 1:

Para " There are some situations..." I think you could slightly adjust the mention of PEPs. For example, a PEP that re-spaces TCP ACKs doesn't have anything to do with the problem mentioned in the first part of the para (about the difficulty of ensuring both clients and servers are upgraded)

Para " More recently, experimentation" I found the first sentence hard to parse. The para seems to use latency to refer to two things (without pointing this out): packet forwarding latency and set-up signalling latency

List of bullets about what a transport converter achieves. I 'd add one to say it achieves 0-RTT - and to explain what 0-RTT means (quite a bit later before the reader discovers this) (and expand the RTT abbreviation)

Section 3:
Figure 2: explain "R"

" Further, the architecture allows for making use of new TCP extensions
   even if those are not supported by a given server."
I find the sentence a bit awkward. Maybe: Further, the architecture enables the use of new TCP extensions between the client and Transport Converter when they are not supported by a server.

Figure 3: I didn't understand why the note is needed "* TLS messages exhanged between the Client and the Server are not shown."

Para under figure 3: This mentions Connect TLVs, which is a mystery concept at this stage. 

Section 1 mostly says TCP extensions, with an occasional TCP options. Be consistent?

Section 3.2:
Figure 5: in the figure title there's "(1)" - what does this mean or is it a typo?

Para " A Transport Converter MAY operate"
"external address" - what does 'external' mean?

Section 4
Should there be a new Section 4.1 that explains the use of port # (to be assigned) to identify Convert protocol messages?

S4.1 title
"fixed header" - is "fixed" needed?

Figure 10:
I think the first "(optional)" should be deleted (ie in bytes 3 & 4)

" In general
   zero padding MUST be added if the value's length in bytes can not be
   expressed as 2+(4 * n)."
better, something like: If necessary, Value MUST be padded with zeroes so that the length of the TLV is a multiple of 32 bits.

" As a general rule, when an error is encountered an Error TLV with the
   appropriate error code MUST be returned by the Transport Converter."
'As a general rule' seems to conflict with 'MUST'

" Transport Converter SHOULD include in this
   list the TCP options that it accepts from Clients and that it
   includes the SYN packets that it sends to initiate connections."
I couldn't parse the second part of the sentence ("and that it...")

" The list of Supported TCP Extension is padded with 0 to end on a 32
   bits boundary."
Replace: The list of Supported TCP Extensions MUST be padded with 0 to end on a 32
   bits boundary.

Section 6
This section actually only discusses one type of middlebox (removes SYN). Can the discussion be widened slightly - or maybe simply say that if middlebox interference detected, then MUST stop using the Converter (with SYN removal given as an example)?

Not yet read Section 7 onwards, comments to follow.

Section 10 Change log
There's lots of really useful info about why the design is as it is (eg the use of TLV rather than Options). It would be a shame if this was lost from the rfc - please can info be extracted into a section "how implementation experiences have influenced design decisions" or similar?


-----Original Message-----
From: tcpm [] On Behalf Of Scharf, Michael
Sent: 25 June 2019 17:39
To: Extensions <>
Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08

Hi all,

draft-ietf-tcpm-converters has been discussed and reviewed quite a bit.

Therefore, this e-mail starts a working group last call (WGLC) for draft-ietf-tcpm-converters-08 that will run until ***July 14, 2019***.

Please let us know if there are any remaining open issues regarding this document. Statements supporting publication are also welcome. In absence of feedback we will assume that the TCPM consensus is to move the document to the IESG. As discussed in the past, the intended status of the document is experimental.

Thanks a lot

(TCPM co-chair) 

tcpm mailing list