From nobody Mon Oct 31 11:55:45 2022 Return-Path: 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 BC015C1526E7 for ; Mon, 31 Oct 2022 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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 wUOM2M2bhi_F for ; Mon, 31 Oct 2022 11:55:39 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 7146BC14CE29 for ; Mon, 31 Oct 2022 11:55:39 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id t4so7655243wmj.5 for ; Mon, 31 Oct 2022 11:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Lsa+ceT+t3fjLbXkVRGDCJ1JfZiVJWVBBCNqK/xUOkc=; b=J0WHaa/2BrQJtFs/5QVaJgZv5ddVj/Y200eWm2zPNkArTHzMcKWysxyusPNnq8Zj5D e3SicaVTs0AiXPRQI/+7yFX7XtMa4X0bRTOpbb0KQZux4/+56rqkVoPRv8NOn6vsQxuI s/fr+74l5m2dC0gZ/ew11I3PcoCBDgRS9IAwexFP5iipDUidECYZM6XGISnG46aUFnbr mBLshdfSs9qCHRGIY+Kvt4xH7hj1DQC0IRjAc+dUBwaODv8jfbcOO7z5D/4wiTo6diA5 UAckiu4iiedNnL6fgjxHbXZZLyWhV6SksPqRmVsvdvk9Ha7Hv8eTtp9JPi585CuzpbDr SHVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=Lsa+ceT+t3fjLbXkVRGDCJ1JfZiVJWVBBCNqK/xUOkc=; b=Jyjq5pRStz+sOQtKDxppDS7eLXXRL1L4k+tQq72xqB1X4DzCMmy4/zvifHw6hhsF65 Bf97hRwAivWF6QnN8zAMWvgGGKnn4RBGm9IOcQPs2o1R5gVzM7iLar8f18pLNwmLXV2p vev8AXn/E0hbX4ZsA/03PaKKpEllOjzgxNXS+GWcpn28p3xpv1HdmUmWIGxK0uHNb9F0 g2HuEUe0Jakx7AU9VPxyBUlW/XYllyxlR+xxS/Zl5LlpcDA/cvPXgmWSmNjjVX2t7oZW u4Tg5qkdD37MWcuc3zgTia1U0RWDgF8YxuUVkmramnPbGKjhudxjMAq7LZJI/k/jjpPx QxbA== X-Gm-Message-State: ACrzQf0VA5GiWROFHT2wqWfHx7XZDqY6rKQaCkCW9ZB0mPW6B1qQ7j5C dIooF94kar1uTfIwifWs9ZVe8X9amNv5M83GKdsHz+dtftg= X-Google-Smtp-Source: AMsMyM5FhRhtFuluM3o2S1GXmB7LlojDjQz6IAd1DYv92+/c1oaG7YqQukc9CsL5Y7Xu9B/UENVP+TPTqkMM3owHlRc= X-Received: by 2002:a1c:f214:0:b0:3be:4e7c:1717 with SMTP id s20-20020a1cf214000000b003be4e7c1717mr9370816wmc.171.1667242537816; Mon, 31 Oct 2022 11:55:37 -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> <689D6379-9DAE-4CC0-A7FF-57E04B2B0352@strayalpha.com> In-Reply-To: From: Yoshifumi Nishida Date: Mon, 31 Oct 2022 11:55:26 -0700 Message-ID: To: "touch@strayalpha.com" , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000038981c05ec592733" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2022 18:55:43 -0000 --00000000000038981c05ec592733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joe, Thanks for the inputs. Sorry, I was not precise enough on the following point. > 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 The sentence meant that the TSO driver behaves as if it disables the feature for this connection. Because no coalescing or splitting by TSO will not happen on the connection (until they support EDO) -- Yoshi On Mon, Oct 31, 2022 at 8:34 AM touch@strayalpha.com wrote: > Hi, Yoshi, > > On Oct 31, 2022, at 1:38 AM, Yoshifumi Nishida wrote= : > > 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. > > > Yes, that=E2=80=99s specifically for legacy TSO adapters. > > 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 > > > No; only incorrectly implemented legacy TSO adapter would need to be > disabled for that connection. > > A legacy TSO adapter that handled unknown options correctly would > basically disable itself, so no application-level action would be needed. > > An EDO-aware TSO would not need to be disabled and would not need to > disable itself. > > 3: EDO can identify wrong TSO behavior if it uses EDO option with segment > length, but cannot with EDO option with simple variant > > > Yes. > > 4: If TSO-enabled adopters support EDO, TSO can be used with EDO without > disabling the feature. > > > Or if legacy TSO implementations either already did the correct thing or > were updated to do the correct thing for unknown options. > > 5: in order to achieve 4:, one approach could be to standardize EDO. > > > Standardizing EDO is already in TCPM charter. > > Standardizing EDO affects only whether/when TSO implementations could > support EDO; either way, incorrectly implemented TSOs can be fixed right > now. > > The better way to think of this is that standardizing EDO can help users > detect incorrectly implemented TSO, which means that bug (of not ignoring > unknown TCP options) can get fixed, which benefits not only EDO but all n= ew > TCP options. > > Joe > > -- > 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 h= ere: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-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 >> >> =E2=80=94 >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com >> >> On Oct 24, 2022, at 10:13 AM, Yoshifumi Nishida >> 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 >>> >>> =E2=80=94 >>> Dr. Joe Touch, temporal epistemologist >>> www.strayalpha.com >>> >>> On Mar 4, 2022, at 11:05 AM, touch@strayalpha.com wrote: >>> >>> Hi, all, >>> >>> I=E2=80=99d 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=E2=80=99re already been around the block w= ith it) or >>> give me the go-ahead to submit it as individual experimental >>> >>> Both drafts are active through April, so I=E2=80=99ll hold on re-issuin= g until >>> (b). >>> >>> Thanks, >>> >>> >>> =E2=80=94 >>> Dr. Joe Touch, temporal epistemologist >>> www.strayalpha.com >>> >>> On Oct 12, 2021, at 1:07 PM, Wesley Eddy wrote: >>> >>> On 10/12/2021 3:50 PM, touch@strayalpha.com wrote: >>> >>> >>> - are there any open issues or pending suggestions to TCP EDO to prepar= e >>> 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 fiel= d >>> experience. At the moment, it seems like QUIC has solved the burning n= eed >>> we had for TCP options space, by attracting all the work that would >>> normally need more options. However, after many years of discussion abo= ut >>> how to handle this for TCP, and many candidates, the EDO approach was t= he >>> 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/experimenta= l if >>> not? >>> >>> Either approach is fine with me, and I prefer either of them rather tha= n >>> 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 mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --00000000000038981c05ec592733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for the input= s.
Sorry, I was not precise enough on the following point.=C2=A0<= /div>

> 2: This means when EDO is used in a conn= ection, TSO will be disabled for the connection as EDO option must be place= d in all segments

The=C2=A0sentence=C2=A0mea= nt that the TSO driver behaves as if it disables the feature for this conne= ction. Because no coalescing or splitting=C2=A0by TSO will not happen on th= e connection (until they support EDO)

--
Yoshi

On Mon, Oct 31, 2022 at 8:34 AM touch@strayalpha.com <touch@strayalpha.com> wrote:
Hi, Yoshi,=C2=A0

On Oct 31, 2022, at 1:38 AM, Yoshif= umi Nishida <nsd= .ietf@gmail.com> wrote:

Hi Joe,= =C2=A0

Thanks for the clarification.=C2=A0
As far as I read the draft, I guess the summaries for EDO with TSO are s= omething like this. Is this correct?

1: EDO can li= ve with TSO adopters if they don't coalesce=C2=A0nor split the segments= with unknown options. If not, they need to be updated.

Yes, that=E2=80=99s specifically for legacy TSO a= dapters.

2: This means when EDO is used in a connection, TSO will be disabled for t= he connection as EDO option must be placed in all segments

No; only incorrectly implemented legacy T= SO adapter would need to be disabled for that connection.=C2=A0
<= br>
A legacy TSO adapter that handled unknown options correctly w= ould basically disable itself, so no application-level action would be need= ed.

An EDO-aware TSO would not need to be disabled= and would not need to disable itself.=C2=A0

=
3: EDO can identify wr= ong TSO behavior if it uses EDO option with segment length, but cannot with= EDO option with simple variant

Yes.

4= : If TSO-enabled adopters support EDO, TSO can be used with EDO without dis= abling the feature.

Or if= legacy TSO implementations either already did the correct thing or were up= dated to do the correct thing for unknown options.

5: in order to achieve 4:, one approa= ch could be to standardize EDO. =C2=A0=C2=A0
=

Standardizing EDO is already in TCPM charter.

Standardizing EDO affects only whether/when TSO implementat= ions could support EDO; either way, incorrectly implemented TSOs can be fix= ed right now.

The better way to think of this is t= hat standardizing EDO can help users detect incorrectly implemented TSO, wh= ich means that bug (of not ignoring unknown TCP options) can get fixed, whi= ch benefits not only EDO but all new TCP options.

= Joe

--
<= div>Yoshi

On Sat, Oct 29, 2022 at 10:45 AM touch@strayalpha.com <touch@strayalpha.com> wrote:
Sure - the is= sue 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:

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

=E2=80=94
Dr. Joe Touch, temporal epistemologistwww.strayalpha.c= om

On Oct 24, 2022, at 10:13 AM, Yoshi= fumi Nishida <ns= d.ietf@gmail.com> wrote:

Hi Joe,=

Thanks for the update. Could you elaborate=C2=A0t= he changes a bit more? I am sorry that I missed what the feedback was.=C2= =A0
--
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 includ= es some long-pending changes based on feedback from Michael Scharf, regardi= ng TSO. It should be ready for WGLC.

Joe

On Mar 4, 2022, at 11:05 AM, touch@strayalpha.com wrote:

Hi, all,

I=E2=80=99d like to= request:

a) WGLC for EDO

b) some sort of WG decision on whether to adopt it as experimental (and, A= FAICT, go to WGLC, given we=E2=80=99re already been around the block with i= t) or give me the go-ahead to submit it as individual experimental

Both drafts are active through April, so I=E2=80=99ll hold= on re-issuing until (b).

Thanks,

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 pe= nding suggestions to TCP EDO to prepare it for last call?

I think it's in good shape for a last call.=C2=A0 It's stable an= d addresses all of the feedback to date, aside from greater implementation = and field experience.=C2=A0 At the moment, it seems like QUIC has solved th= e burning need we had for TCP options space, by attracting all the work tha= t would normally need more options. However, after many years of discussion= about how to handle this for TCP, and many candidates, the EDO approach wa= s 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 i= t 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.=C2=A0 I would be willing to contri= bute 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 mailing list
tcpm@ietf.org
https://= www.ietf.org/mailman/listinfo/tcpm

--00000000000038981c05ec592733--