Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion
Yoshifumi Nishida <nsd.ietf@gmail.com> Mon, 31 October 2022 08:38 UTC
Return-Path: <nsd.ietf@gmail.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 33506C14CEFC for <tcpm@ietfa.amsl.com>; Mon, 31 Oct 2022 01:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SobdNT1L-bQ for <tcpm@ietfa.amsl.com>; Mon, 31 Oct 2022 01:38:50 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB16C14F74D for <tcpm@ietf.org>; Mon, 31 Oct 2022 01:38:49 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id k8so14933210wrh.1 for <tcpm@ietf.org>; Mon, 31 Oct 2022 01:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=se0OAgvFEx2K3pB5wLIaCN+UbhvjKlPcoBBvTN79tAI=; b=AbDlHAbJ3ZhdDD8+OvHQoM6/yJWnc5Cw+5rIb4fowhhH1mMhHMBheg4a+230GB7Aok +QFjWJHyUB1zMo6mCAAmoYxE1LvZkkPpeNuWBfrgSVgephCc5UeLVoR47bqoDQ06BVAc SV7k7yo2Knz0fsv8JZjqNRBf+rRysNPHsLgLbOI1+Sg+TYGfLnSj4Hu3A7YKw8ZUcyAg yiC2vYU2iSupqm66kQBCuogfcSqRMzOeEYw8ypUeBpIEAr93J5WPrPb74/NIdYm+LZGQ l3L82vkMBnaqZ4dUzYTqh973dw2O3WjNroenR1o23GaIWCu0iGtcv0pXoBnc607S1bE0 /1JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=se0OAgvFEx2K3pB5wLIaCN+UbhvjKlPcoBBvTN79tAI=; b=qt7RphwZ/Loo6r2lUlWeZ2EeEwrsW0Y/NWBNi1kog6cTQQ1xxvSx/8VfdhxuiuhMrG J72mJA8DzjqDbC7yToHBfv4egpxk5+HAXM3CuCtdL6L53h6W+ZrJDRYcNyXPDB7mKhLu /elLVmCdn8Kx6AAq6n/Ujn6zJrhESc051PvAQt5e6qHX2K7z4p38rv7yuKqqo5LpRqCi r3sys5yDQbj3d5qPXSmALVUNhKLU8ZfmBswViM4YiZvftiHRaq1djqWj7F1orXggUfmg 5Sox+lxljPm6hDQ1D2LkMLiVKJI/gSNrAFoi1Kt8bCOtrplyZUVT+/5Fk+SX63hV9ZrT 7jWA==
X-Gm-Message-State: ACrzQf0AAZG2Da+81K2NXxrMOsBrLCDo9jaLPutDxI0VmNzcHUBOJKYW hNxNYlqmAlbNYEaE3qJ6qMHFSu5Q6A252irvRuyA6byo
X-Google-Smtp-Source: AMsMyM5fq+ucYdOk+X32xTiiEpUEKHnAHM/jvoKCTjjR6BPHlFgKAqEBqrdYp0lYzVkC2j3NTrQmxWZGUzUspM6rc28=
X-Received: by 2002:a05:6000:a09:b0:236:6b18:6b30 with SMTP id co9-20020a0560000a0900b002366b186b30mr7626261wrb.356.1667205527634; Mon, 31 Oct 2022 01:38:47 -0700 (PDT)
MIME-Version: 1.0
References: <0FF01EB8-C286-481D-9694-673DC3C59C7A@strayalpha.com> <96c57846-bb58-d186-82a1-dac649370602@mti-systems.com> <0102C65C-1847-4DD6-8624-50C25E1A2AD2@strayalpha.com> <4CDA7158-89EA-4833-9636-74595E96F739@strayalpha.com> <CAAK044RP0vE8U0go9bZHaqCW6pcduVyMo7KQNBbtfwReN5O5kw@mail.gmail.com> <689D6379-9DAE-4CC0-A7FF-57E04B2B0352@strayalpha.com>
In-Reply-To: <689D6379-9DAE-4CC0-A7FF-57E04B2B0352@strayalpha.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Mon, 31 Oct 2022 01:38:36 -0700
Message-ID: <CAAK044QQQeJBPw0CmqhC3Js6wr-aLw0_pH+vLVTytZJ3JrCXtw@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: tcpm <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003e08b005ec50897f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/uxAbalfaPkIBvg-aLVGLDnVdNbE>
Subject: Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 31 Oct 2022 08:38:54 -0000
Hi Joe, Thanks for the clarification. As far as I read the draft, I guess the summaries for EDO with TSO are something like this. Is this correct? 1: EDO can live with TSO adopters if they don't coalesce nor split the segments with unknown options. If not, they need to be updated. 2: This means when EDO is used in a connection, TSO will be disabled for the connection as EDO option must be placed in all segments 3: EDO can identify wrong TSO behavior if it uses EDO option with segment length, but cannot with EDO option with simple variant 4: If TSO-enabled adopters support EDO, TSO can be used with EDO without disabling the feature. 5: in order to achieve 4:, one approach could be to standardize EDO. -- Yoshi On Sat, Oct 29, 2022 at 10:45 AM touch@strayalpha.com <touch@strayalpha.com> wrote: > Sure - the issue was clarifying the way in which EDO interacts with TCP > segment offload (TSO). The diffs are at the end of section 9, as shown here: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-13.txt > > The goal is to be more clear that this is a bug in TSO that EDO adopters > need to be on the lookout for. > > Joe > > — > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > On Oct 24, 2022, at 10:13 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> > wrote: > > Hi Joe, > > Thanks for the update. Could you elaborate the changes a bit more? I am > sorry that I missed what the feedback was. > -- > Yoshi > > On Sat, Oct 22, 2022 at 4:25 PM touch@strayalpha.com <touch@strayalpha.com> > wrote: > >> FYI - both docs have been updated. >> >> The EDO doc includes some long-pending changes based on feedback from >> Michael Scharf, regarding TSO. It should be ready for WGLC. >> >> Joe >> >> — >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com >> >> On Mar 4, 2022, at 11:05 AM, touch@strayalpha.com wrote: >> >> Hi, all, >> >> I’d like to request: >> >> a) WGLC for EDO >> >> b) some sort of WG decision on whether to adopt it as experimental (and, >> AFAICT, go to WGLC, given we’re already been around the block with it) or >> give me the go-ahead to submit it as individual experimental >> >> Both drafts are active through April, so I’ll hold on re-issuing until >> (b). >> >> Thanks, >> >> >> — >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com >> >> On Oct 12, 2021, at 1:07 PM, Wesley Eddy <wes@mti-systems.com> wrote: >> >> On 10/12/2021 3:50 PM, 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 >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >
- [tcpm] TCP EDO and SYN-EXT-OPT finalization - req… touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Wesley Eddy
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… mohamed.boucadair
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… mohamed.boucadair
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com
- [tcpm] call for feedback on SYN-EXT-OPT draft Yoshifumi Nishida
- Re: [tcpm] call for feedback on SYN-EXT-OPT draft touch@strayalpha.com
- Re: [tcpm] call for feedback on SYN-EXT-OPT draft touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Joe Touch
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… Yoshifumi Nishida
- Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization -… touch@strayalpha.com