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
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- [tsvwg] Comments on ietf-106-tsvwg-udp-options C. M. Heard
- Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options Joe Touch
- Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options C. M. Heard
- Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options Tom Herbert
- [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert
- Re: [tsvwg] Rregarding soft-state and UDP options C. M. Heard
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Joe Touch
- Re: [tsvwg] Rregarding soft-state and UDP options Tom Herbert