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

"C. M. Heard" <heard@pobox.com> Mon, 30 December 2019 00:28 UTC

Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8B6BC1200F9 for <tsvwg@ietfa.amsl.com>; Sun, 29 Dec 2019 16:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HgyzpZc9B9yd for <tsvwg@ietfa.amsl.com>; Sun, 29 Dec 2019 16:28:56 -0800 (PST)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185211200F8 for <tsvwg@ietf.org>; Sun, 29 Dec 2019 16:28:55 -0800 (PST)
Received: from pb-smtp2.pobox.com (unknown []) by pb-smtp2.pobox.com (Postfix) with ESMTP id 8397A2AEDD for <tsvwg@ietf.org>; Sun, 29 Dec 2019 19:28:54 -0500 (EST) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=+1/dAK OPurWB1dwmwAtU7mBEhSs=; b=GDrCZpsNSbEgBIjJM8hTiVWqSMp5n4EVRxuPMm jRD3sL5vWFhHmNYR1Z5Lu623FR0Kdn2wRW62Ri7bVvaXVDQ3gBP9L9vgoX5pj1r2 72OC2X2m4DKhQFYf5qmxQB2H3G4LbaxtCE9VZ7HW9oOVqI6zpTsPnpxyPTc5yHpN rzP64=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= Ca6MeAK2XtYZlvQ+2iJrFeb8hfFYPKPhXvspVLFPQMUhurnTkDtT/XOP5KcxlYxH vaow/dnpUAHHYeDnnN3AZ8y1KivWAo6lYlXhrv/lgPqSLaFFMNWaUfzj/uCEMR+4 PDJLMBuFlgI5ogiHptErCuzBDsep5aZYIms80h8ytoM=
Received: from pb-smtp2.nyi.icgroup.com (unknown []) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7C9432AEDB for <tsvwg@ietf.org>; Sun, 29 Dec 2019 19:28:54 -0500 (EST) (envelope-from heard@pobox.com)
Received: from mail-io1-f48.google.com (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 03EF62AEDA for <tsvwg@ietf.org>; Sun, 29 Dec 2019 19:28:54 -0500 (EST) (envelope-from heard@pobox.com)
Received: by mail-io1-f48.google.com with SMTP id v18so30210288iol.2 for <tsvwg@ietf.org>; Sun, 29 Dec 2019 16:28:53 -0800 (PST)
X-Gm-Message-State: APjAAAXWxRUHxs+RaOK3q0p34a8Y1TytyRvLJbW6tQmtMPggik6wDSyY mjeI+a1oKdBQuNTsksZsq6qeUwgLb96D2MqEMxQ=
X-Google-Smtp-Source: APXvYqzzJYfC9pKbruwSkVED5KBMLurP/oRxTIsjKipYW6ryHnFKyRYqy00uu4YWjx83Woh7fMlc4xQ3JfKLkITbRqw=
X-Received: by 2002:a6b:d20c:: with SMTP id q12mr41720083iob.143.1577665733367; Sun, 29 Dec 2019 16:28:53 -0800 (PST)
MIME-Version: 1.0
From: "C. M. Heard" <heard@pobox.com>
Date: Sun, 29 Dec 2019 16:28:41 -0800
X-Gmail-Original-Message-ID: <CACL_3VF_Mi6JFK=so_P57+Woe5PYOzC4o2Okj6BPVzB91scRQg@mail.gmail.com>
Message-ID: <CACL_3VF_Mi6JFK=so_P57+Woe5PYOzC4o2Okj6BPVzB91scRQg@mail.gmail.com>
To: TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ca3fd059ae0eddb"
X-Pobox-Relay-ID: 5C049FC6-2A9B-11EA-863C-D1361DBA3BAF-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qUtvvq78nnrizdxZmBuXUuVqPDI>
Subject: [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: Mon, 30 Dec 2019 00:28:59 -0000

Slide 3 of 4 of the IETF 106 UDP Options presentation, entitled "Issues
posted Sep 2019" covered the items below; see comments in-line.

On Thu, Sep 12, 2019 at 9:30 PM Joe Touch wrote:

> Hi, all,
> A summary of some other issues:
> - regarding PADN
> I have not been able to identify a need for this vs. use of EOL and
> zero-fill for the remainder of the surplus area. If anyone can show a
> need for this *in a transport protocol*, please indicate.

If my understanding is correct, the primary motivation for the proposal to
include both PAD1 and PADN was to have UDP options use the same format
as IPv6 options. As the IETF 105 presentation notes, it's easy to add
PADN, but it's impossible to match both TCP ***and*** IPv6 codepoints.
I personally am comfortable with a decision to align with TCP (and IPv4)
codepoints, i.e., to retain the present PAD and EOL definitions.

- regarding LITE, FRAG, LITE+FRAG
> (working on text now)

Slide 4 of 4 states:
  – LITE+FRAG to be supported
  – LITE alone to be removed
  – FRAG alone to be removed

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.

During the e-mail discussion in the weeks prior to IETF 105, I proposed
an additional design requirement to supplement those set forth in
(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, 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.

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;
(b) user data shall be transported using that mechanism whenever it is
accompanied by an option that affects how it is processed; 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.

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

One way to accomplish (a) would be the version of FRAG proposed in
(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. As an example, AE
(Authentication and Encryption), as defined in the current spec, affects
the processing of the user data, but an implementation is not required
 to support it. More generally, if an option that affects data
handling (such as compression) is defined in the future, option-aware
receivers that implement the current spec won't recognize it. They need
a means to determine whether it's safe to ignore the option and deliver
the user data or whether to discard both the data and the option.

One way to accomplish (c) would be to reserve a bit in the Option Kind
for that purpose. The latter is what I assume is meant by a "must
support" FLAG. I think that's a misleading name; IMO would be more
accurate to call it a "safe to ignore" flag. I believe that the
above discussion establishes an essential use for this flag.

Mike Heard

*The requirements were:
1- support options
2- allow at least some options to be silently ignored by legacy receivers
(to enable ‘“optionally enhanced” exchanges)
3- allow at least some options to be required
4- allow the options themselves to be protected
5- support for fragmentation/reassembly
6- support for MTU discovery
7- support (optional) middlebox checksum/payload length bug traversal
8- support LITE, i.e., where some of the payload is not covered by at least
some checksum processing

With the probable exception of #8, I believe that these are still current.