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