Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion

"" <> Thu, 14 October 2021 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC6E63A1721 for <>; Thu, 14 Oct 2021 09:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wVqBBJ4r3p3e for <>; Thu, 14 Oct 2021 09:14:43 -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 17B5C3A171A for <>; Thu, 14 Oct 2021 09:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=Y4MeEoInN4LoMbgOQ19EIh+XtIrMfu71qMNpdbXPCWs=; b=ANydOlrEL5QDTuhk5oTb4/0hP4 a2mnIRj6LFXk7iM7E005AP+jMrlYFqnfM6jVsImbPKB1iP7kJs5FPzXwVHFtCWtVTLcUbH9busG7t K7sZ1pEAIx4HldWTjzgjS8N37wgVxuSN/XRP6+2iJjUWPP/EdrT0PVEIAVItXGZs8RBsnUGcjTclR 0rtTBUDsiGtiOlG6FKLjaHGapjofaHznds7Wi00w00dENRYJlkTwZounpNom7Gn4nE/XR5kvaZLFq 7I4qaXHcOUtoOazxvX+bky051zwSi0xa868chkRMQXzVMrN8WEe9YcNQBPNzVIQcGVNdCOw/SpQ3F IzLQST4g==;
Received: from ([]:52896 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1mb3NN-00FBOW-5v; Thu, 14 Oct 2021 12:14:42 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_25F0A1FC-BC05-4ED7-9F64-38AF89DBC4A5"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: "" <>
In-Reply-To: <>
Date: Thu, 14 Oct 2021 09:14:36 -0700
Cc: tcpm <>
Message-Id: <>
References: <> <> <23584_1634116047_6166A1CF_23584_209_1_787AE7BB302AE849A7480A190F8B93303542B124@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <> <>
To: Yoshifumi Nishida <>
X-Mailer: Apple Mail (2.3654.
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] TCP EDO and SYN-EXT-OPT finalization - request for discussion
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, 14 Oct 2021 16:14:48 -0000

Hi, Yoshi,

> On Oct 13, 2021, at 6:51 PM, Yoshifumi Nishida <> wrote:
> Hi Joe,
> On Wed, Oct 13, 2021 at 9:01 AM <> < <>> wrote:
> Hi, Yoshi,
> Although I noticed that post, there are two issues that make it not really comparable to SYN-EXT:
> - SYN-EXT extends the space available to all options, whereas AGG-SYN compresses existing options
> 	a single option of larger than 40 bytes can be supported in the former but not the latter
> - SYN-EXT is compatible with connections to legacy receivers; AGG-SYN does not appear to be
> 	a SYN-EXT endpoint can put the options it expects/needs in the SYN with a 2-byte SYN-EXT option overhead
> 	by compressing existing options, AGG-SYN effectively redesigns TCP such that legacy receivers would require an additional round-trip to recover
> One you have anything like the AGG-SYN option in a SYN, you’ve effectively redesigned TCP and can do anything you want, as the doc suggests - add additional RTTs for coordinate, etc. But that comes at the expense of legacy receivers and middle boxes, which can no longer rely on tracking the existing 3-way handshake.
> Once you’ve taken that step, you might as well just use a new transport code point and design a new protocol…
> While I understand your points, I would like to mention that the method proposed in the draft is basically the same as what mptcp already does.

That works for MPTCP because *it* has decided that some aspects of its protocol are negotiated after the 3WHS. Each option can decide that for itself, but we cannot decide that for the initial exchange of all options (which is what needs to be done to extend the SYN option space).

> If this looks like designing a new protocol, I think mptcp can also be viewed as a new protocol. (you may say so, though..)

It is - after the 3WHS decides “MPTCP enabled”, MPTCP runs its own, possibly lossy and out-of-order processing of its options to coordinate its state. That’s all “inside” MPTCP, though.

> So, I'm not very sure delaying option negotiation looks like a more drastic change than using OOB packets.

It is - MPTCP has decided it is OK to delay negotiation for some of its parameters, but we cannot unilaterally do that for existing options.

> Also, I am not sure which one is more legacy receiver friendly as both approach send a new option kind in the first SYN and the feature is disabled if the option is ignored. 

“Legacy” needs to accommodate both legacy receivers and legacy options.

For legacy receivers, the best we can do is avoid an extra RTT to do the SYN-ACK to confirm the options in the existing SYN space, i.e., there’s no way to extend its option space.

For upgraded receivers, we want to avoid extra RTTs to extend the actual (not available) space in the SYN; SYN-EXT-OPT is the only method currently shown (AFAICT) that has that capability.

(Note: again, I encourage you to separate the multiple RTT delayed option negotiation from the option compression part; they don’t need to be related)