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

"touch@strayalpha.com" <touch@strayalpha.com> Wed, 13 October 2021 16:01 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941603A0BCB for <tcpm@ietfa.amsl.com>; Wed, 13 Oct 2021 09:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ_FuDj5LQd6 for <tcpm@ietfa.amsl.com>; Wed, 13 Oct 2021 09:01:13 -0700 (PDT)
Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8771E3A0BC6 for <tcpm@ietf.org>; Wed, 13 Oct 2021 09:01:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=WyzgoSm3taQsFTyJi7ddSPDZqrceGsea1/oTrInChVY=; b=4IhTZXOKUyAljbQ5ha6SOV7L8d Xsof/LVWu8xHgkyfWwA7W32H+wgZv/nREN/Q5SXcBJVAxKyA1vaHg/g5BSzJVEShIHeCO0AK30kSA O+uDGzDW52Vx8izHZx/TGXLifs/43a6bdy9eXG2oFR5tr2EKn+4Qm4ik7evgYSl/2RjfYCWWYulJe 3Q0GX7fL7V80Z+ifg3vt9zxCjVSEf+GXSSM7MyoY+zt+7XfoCUHYa0OAwnYZjw5O27CMH3AuzNQzH PJAX6YP5SE/FThTCuohJDM7COHM/SRXFctbvLtbQ9uimeVQAidZM0DTx0GroJ3vNdY0kSt82DXzbs bI+4UnXA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:55096 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1maggl-0098Ks-6l; Wed, 13 Oct 2021 12:01:12 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_26BA734C-8FE4-472C-81F7-DE8AF88253E6"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CAAK044TGV0tE0q9RHbctKQLLpg6+gA6=0YMeQ6Gxcm1FqUjYXg@mail.gmail.com>
Date: Wed, 13 Oct 2021 09:01:05 -0700
Cc: mohamed.boucadair@orange.com, tcpm <tcpm@ietf.org>
Message-Id: <CDE3205B-7CE7-4FB1-A44D-52104A2EAA5F@strayalpha.com>
References: <0FF01EB8-C286-481D-9694-673DC3C59C7A@strayalpha.com> <96c57846-bb58-d186-82a1-dac649370602@mti-systems.com> <23584_1634116047_6166A1CF_23584_209_1_787AE7BB302AE849A7480A190F8B93303542B124@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAAK044TGV0tE0q9RHbctKQLLpg6+gA6=0YMeQ6Gxcm1FqUjYXg@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BCFhK7z4n5XbLruJTfZU0G0Pb5o>
Subject: Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2021 16:01:19 -0000

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…

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Oct 13, 2021, at 3:15 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
> 
> Hi Med,
> FWIW, I wrote https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00.txt <https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00.txt> which can extend SYN option space without using OOB packets.
> As SYN option space extension is an important and fundamental feature, I personally prefer to discuss the doc at the WG.
> --
> Yoshi
> 
> On Wed, Oct 13, 2021 at 2:07 AM <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> wrote:
> Hi all, 
> 
> I agree with Wes. 
> 
> Solving the SYN case is more problematic (e.g., consider an application relying upon MP_CAPABLE + FAST_OPEN). We managed to solve this specific issue in RFC8803 without requiring SYN-EOS/OOB, but that approach cannot be generalized. Having a tcpm WG document to cover the SYN case + discuss the issues of an OOB mechanism is useful.    
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : tcpm <tcpm-bounces@ietf.org <mailto:tcpm-bounces@ietf.org>> De la part de Wesley Eddy
> > Envoyé : mardi 12 octobre 2021 22:07
> > À : touch@strayalpha.com <mailto:touch@strayalpha.com>; tcpm <tcpm@ietf.org <mailto:tcpm@ietf.org>>
> > Objet : Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for
> > discussion
> > 
> > On 10/12/2021 3:50 PM, touch@strayalpha.com <mailto:touch@strayalpha.com> wrote:
> > >
> > > - are there any open issues or pending suggestions to TCP EDO to
> > > prepare it for last call?
> > >
> > I think it's in good shape for a last call.  It's stable and addresses all
> > of the feedback to date, aside from greater implementation and field
> > experience.  At the moment, it seems like QUIC has solved the burning need
> > we had for TCP options space, by attracting all the work that would
> > normally need more options. However, after many years of discussion about
> > how to handle this for TCP, and many candidates, the EDO approach was the
> > one the working group was able to get consensus around, and we really
> > should wrap up and publish it, IMHO.
> > 
> > 
> > > - would the WG like to adopt SYN-EXT-OPT as experimental as well or
> > > would it be preferred (and OK) to submit this as
> > > individual/experimental if not?
> > >
> > Either approach is fine with me, and I prefer either of them rather than
> > not advancing anything.  I would be willing to contribute reviews for
> > either path.
> > 
> > 
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org <mailto:tcpm@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm