Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options

"C. M. Heard" <heard@pobox.com> Wed, 01 January 2020 19:58 UTC

Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607E312004D for <tsvwg@ietfa.amsl.com>; Wed, 1 Jan 2020 11:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 pxYGlbREEdsU for <tsvwg@ietfa.amsl.com>; Wed, 1 Jan 2020 11:58:56 -0800 (PST)
Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12A312001A for <tsvwg@ietf.org>; Wed, 1 Jan 2020 11:58:55 -0800 (PST)
Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C945723EEC for <tsvwg@ietf.org>; Wed, 1 Jan 2020 14:58:54 -0500 (EST) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=zj3K3AsDOd6Utbh3M6PbJhHLVus=; b=B9VCe0 De9AA7Z5gF7eplA5m6guRkGx+ul1gBeqTdpppCPIIMo4T9VF5Qe06OKrZuozjJQ+ XmHpY3rItzvIPrfEkaeLXSoqfqFNvuJWp3ZiUdcReIRYCo10Hr1LmCenOo8/R2H6 VYbTEhWFbYcawPMFmVE5BWhe2mnNrY7Y9q7UY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=BmwR2UBvrfWP5bweAocnOBUSVH6ajkPx Saae1VVcDzpGpR4pA4x7ZBTXK8lczqyUtZkxyeNCtxrHPedhwzwbG9SHOPGt4LHw s4U4OYmVp4h0Ete0VnhUHgwxQ5r8RvCgmjtNAnM5Dj+nYMqDxfN2fv7BtH2QZ6RY vvhS2e+YgBU=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C153623EEA for <tsvwg@ietf.org>; Wed, 1 Jan 2020 14:58:54 -0500 (EST) (envelope-from heard@pobox.com)
Received: from mail-il1-f182.google.com (unknown [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 4635823EE7 for <tsvwg@ietf.org>; Wed, 1 Jan 2020 14:58:54 -0500 (EST) (envelope-from heard@pobox.com)
Received: by mail-il1-f182.google.com with SMTP id v15so32729082iln.0 for <tsvwg@ietf.org>; Wed, 01 Jan 2020 11:58:54 -0800 (PST)
X-Gm-Message-State: APjAAAUVPFgCQvSq5rQWwFI8fk6aK4T8FD33AOo9gE0qwrUCRSWb3wpc eqATFUYBVMRWhuHTV4IvrL8y7svnrbKniQzuglg=
X-Google-Smtp-Source: APXvYqwJwBXJJcA7Q92AtYQYz07t3cWHp4TluGZNyACZA7A9ugi75hARn20eAbsSLyzJ8gywK4+9PreJjKhvG+UKONQ=
X-Received: by 2002:a92:381b:: with SMTP id f27mr69789008ila.291.1577908733775; Wed, 01 Jan 2020 11:58:53 -0800 (PST)
MIME-Version: 1.0
References: <CACL_3VF_Mi6JFK=so_P57+Woe5PYOzC4o2Okj6BPVzB91scRQg@mail.gmail.com> <40B548AC-6168-46B5-81F8-CB6A64C83D5C@strayalpha.com>
In-Reply-To: <40B548AC-6168-46B5-81F8-CB6A64C83D5C@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Wed, 01 Jan 2020 11:58:42 -0800
X-Gmail-Original-Message-ID: <CACL_3VEmX6C-Mqz8OQuS2NtJQPNNFgyTgyb9uN6TrHuZYwLMLA@mail.gmail.com>
Message-ID: <CACL_3VEmX6C-Mqz8OQuS2NtJQPNNFgyTgyb9uN6TrHuZYwLMLA@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000909619059b1981b8"
X-Pobox-Relay-ID: 2376E2F8-2CD1-11EA-AA52-C28CBED8090B-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/MJiaSEZ2kYNHSP3YlOkKD4j91F4>
Subject: Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jan 2020 19:58:58 -0000

On Tue, Dec 31, 2019 at 7:09 AM Joe Touch wrote:

> Thanks for the feedback, Mike.
>

Thank you for the reply.


> Regarding the MUST SUPPORT flag part:
>
> On Dec 29, 2019, at 4:28 PM, C. M. Heard <heard@pobox.com> wrote:
> ...
> I'll comment when the updated text appears.
>
>
>> - regarding MUST SUPPORT flag
>>
>> The only need for this flag has been data that must not be received by
>> legacy endpoints, e.g., compressed. That's already achievable more
>> flexibly using the FRAG+LITE with pre and post reassembly options. Can
>> anyone show a case this doesn't cover?
>>
>
> I disagree with this characterization, both of the proposed change and
> the purpose that it serves.
>
>
> I made two claims:
> 1. the need is for data that shares fate with the option on legacy
> endpoints (is ignored)
> 2. the need is already addressed by pre and (notably) post-reassembly
> options in FRAG+LITE
> I was assuming FRAG that supports the degenerate case of a single fragment.
>
> During the e-mail discussion in the weeks prior to IETF 105, I proposed
> an additional design requirement to supplement those set forth in
> https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c
> (and also in the IETF 105 presentation slides).* It was:
>
> - Any option that affects the handling of the user data must share fate
> with that user data,…
>
>
> As noted above, already supported by FRAG+LITE.
>
> in the following sense: either the option and the
> user data are processed together, with the data and option indication
> being delivered to the user if the processing succeeds, or else both are
> discarded, and nothing is delivered to the user. This requirement
> applies to all receivers, legacy or otherwise.
>
>
> That’s accomplished by post-reassembly options.
>
> I do not believe that the spec, either in previous incarnations or in
> its current (-08) form, provides a way to satisfy this requirement. In
> order to fill that (perceived) gap, I proposed that (a) there shall be
> a means to transport user data in the options area with OCS coverage;
>
>
> As noted in the update, OCS covers the entire option area now (which thus
> includes FRAG+LITE).
>
> (b) user data shall be transported using that mechanism whenever it is
> accompanied by an option that affects how it is processed;
>
>
> The user makes this decision by selecting to use an option “post
> reassembly”.
>

OK, I'll wait for the promised update to FRG+LITE appears before I make
further comments.

> and (c)
> the Option Kind space shall be subdivided into two ranges, one for
> options that do not affect the handling of user data and another for
> options that do affect the handling of user data.
>
>
> That’s a mechanism - one that is not needed to achieve the other goals.
>
> Note that (a) and (b) are needed to ensure that user data accompanied by
> an option that affects its processing is not delivered to a legacy
> receiver (which ignores all options) or to an option-aware receiver
> when OCS fails (for in that case, the option-aware receiver also
> ignores the options).
>
>
> a) and b) are already supported.
>
> One way to accomplish (a) would be the version of FRAG proposed in
> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg
> (other alternatives have also been discussed). I'll defer further
> discussion of the details until after I see the new LITE+FRAG option.
>
> Note that (c) is needed to ensure that user data accompanied by
> an option that affect its processing is not delivered to an option-aware
> receiver that does not recognize the option.
>
>
> We have already described how this should be achieved using soft-state
> negotiation between the endpoints.
>

I have reservations about the adequacy of using soft-state negotiation for
this
purpose. There are two issues I see: (1) the negotiation mechanism in the
current
draft is, in my opinion, underspecified; (2) it won't work for a
unidirectional
communication path. I'll give myself a homework assignment to be done while
I
await the new FRAG+LITE text: prepare text to fix (1) and come up with a
convincing use case for (2).

Thanks & regards,

Mike Heard