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

Yoshifumi Nishida <> Fri, 15 October 2021 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 791A93A27F8 for <>; Fri, 15 Oct 2021 15:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rZMZUKnlzC5k for <>; Fri, 15 Oct 2021 15:53:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39B973A1258 for <>; Fri, 15 Oct 2021 15:48:32 -0700 (PDT)
Received: by with SMTP id z24so10145779qtv.9 for <>; Fri, 15 Oct 2021 15:48:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uTBtY2qAow4L6pOQCetWOUbp57wvrXqYj7nQ5mZkKoE=; b=LUVACwMBPfGeaCTpwuTEeWobfKsQNDA/20+nl9cM3TzWIVhC+DsEGWL8utVUJ/ZO3d +JDtLO4I8uBiTfeZ9Jw6iDpYvHP2+RmQncp/lb/v2+I4TNY/3FLcHjDgT7uSGLFfS/dY 8HtZLSWueZcdktWWF+SBxD4ZX9EWsCl/AtqbkQjdk/BJmfiToalneKjr7GlBEHauAA06 Mac2nC4W9o+ZB9IbxfZoTsbx/Bf/YrG6cMKkg5vFUYRlLm09qoZV6uxqPURdH4D6PrgP SGq+VMc88OnTnoR4YhIXAwIJs2/KPgRdicBNepDh8mfj/vx5Y4ciWTUjkwwgPQHAUEd9 2R7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uTBtY2qAow4L6pOQCetWOUbp57wvrXqYj7nQ5mZkKoE=; b=gp0n2+ApxPo8dnp7Vqj1e0dqhEWvyy84kMG/CQ7wk7B2ZOIVVmyYoinGcUfINnK3lX gDwJ1U+Vgpd1Do0VdkYTB6pgt9N/yR5pknntuNWAUCydPOO+Gbwyrxfb6iUiLJyBxgKh 2TQJssFIizG5Jb/dMoM4Ep7XLjxojI9ic5m/OmQ/Rwhlc4an6WZWTpZxxEDStqnTiWci 7iM54v6VcTEx4OKtPNJNA26IxwhPNJTxgzdU6gz/ehkEwcY8H4ZfwWZLa+xQz3KvJa4H abJeSIAgXHtB8IXYEBzY14YXB4InDt4rJgKzRPYvjsy5SYEuAIzusHxxmSC+ftqzvQzV mipA==
X-Gm-Message-State: AOAM53319pQDqb7XOhkyKrWKdCvtI/vYHUX7HFMA7f4ngn114BMGl04z MEF0ZW7gJ02WAE8mMbdJ2pGDSOfn7j3bRVtVkI0L2EHTtsM=
X-Google-Smtp-Source: ABdhPJwvshp8Xfb38gx2j66s/gP/9dRU4l4eLhEi4ieBSYR4UkaoI8O+kZ9+6jZovGtBViSUFifSK2Fn+/sb7bHOOg0=
X-Received: by 2002:a05:622a:1187:: with SMTP id m7mr16313231qtk.336.1634338109769; Fri, 15 Oct 2021 15:48:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <23584_1634116047_6166A1CF_23584_209_1_787AE7BB302AE849A7480A190F8B93303542B124@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <> <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Fri, 15 Oct 2021 15:48:18 -0700
Message-ID: <>
To: "" <>
Cc: tcpm <>
Content-Type: multipart/alternative; boundary="00000000000079cacf05ce6bfe78"
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: Fri, 15 Oct 2021 22:54:01 -0000

Hi Joe,

On Thu, Oct 14, 2021 at 9:14 AM <>

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

Yes, I understand your points and I have a different view. I might want to
see some feedback from other folks on this.

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

OK. my proposal recommends incremental deployments as described in Section
5.1 for regacy receivers.

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

Right. if it makes things easier, I can split this proposal into two.
in any case, if we keep inventing new options, I think something like
AGG-SYN option will be needed some day