Re: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

Kangjiao <> Wed, 10 February 2021 01:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5590E3A1118 for <>; Tue, 9 Feb 2021 17:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tl9e3PBFUgah for <>; Tue, 9 Feb 2021 17:14:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5A6D3A1116 for <>; Tue, 9 Feb 2021 17:14:18 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Db1sN5Fxxz67lyl; Wed, 10 Feb 2021 09:10:32 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Feb 2021 02:14:12 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Feb 2021 02:14:12 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 10 Feb 2021 02:14:12 +0100
Received: from ([]) by ([]) with mapi id 14.03.0509.000; Wed, 10 Feb 2021 09:14:04 +0800
From: Kangjiao <>
To: Yoshifumi Nishida <>, " Extensions" <>
CC: Liangqiandeng <>
Thread-Topic: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
Thread-Index: AQHW+fwAzocl9W3Fpky4agCZWo0PP6pQnyjQ
Date: Wed, 10 Feb 2021 01:14:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_719A2C1D4AC73847B6E1BF21DF1545EAE5E77372dggemm514mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
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: Wed, 10 Feb 2021 01:14:21 -0000

Hi Yoshi,

I wrote a draft to propose an idea for MPTCP subtype capability exchange during MPTCP handshake.  We think, in MPTCP, some options are mandatory but some options can be set as optional ones. So an exchange mechanism of actual capability between both parties are needed.


When I read your draft, I think maybe our above work have some relevance to your suggestions. If you think it'll help with this work, I hope we can discuss this new negotiation mechanism for related options and subtypes. Thanks

Best wishes,

From: tcpm [] On Behalf Of Yoshifumi Nishida
Sent: Wednesday, February 3, 2021 3:12 PM
To: Extensions <>
Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

Hi folks,

I prepared a draft for SYN option space extensions.
I know this is a difficult issue in TCP and has been discussed for a long time.
But, I'm thinking that it might be a good time to discuss it again.

Key ideas of the draft are the followings.
1: drastic changes in TCP's spec will not be required
    (it does not require updating TCP header format nor using multiple SYN packets or additional SYN-like packets)
2: utilize the option negotiation schemes in mptcp for generic purposes. so, I think it can be considered middlebox friendly.
3: it has some limitations (e.g it can only extend around 30-40 bytes for SYN option space). But, if it's combined with EDO, we can use more option space.
    (depends on how EDO draft will progress, though)

Please let me know if you have any questions or comments or suggestions.

Thank you so much!

---------- Forwarded message ---------
From: <<>>
Date: Tue, Feb 2, 2021 at 10:45 PM
Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
To: <<>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Aggregated Option for SYN Option Space Extension
        Author          : Yoshifumi Nishida
        Filename        : draft-nishida-tcpm-agg-syn-ext-00.txt
        Pages           : 14
        Date            : 2021-02-02

   TCP option space is scarce resource as its max length is limited to
   40 bytes.  This limitation becomes more significant in SYN segments
   as all options used in a connection should be exchanged during SYN
   negotiations.  This document proposes a new SYN option negotiation
   scheme that provide a feature to compress TCP options in SYN segments
   and provide more option space.  The proposed scheme does not update
   the format of TCP header nor transmit any additional SYN or SYN-like
   segments so that it has lower risks for middlebox interventions.  In
   addition, by combining another proposal for option space extension,
   it is possible to provide further option space.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list<>
Internet-Draft directories: