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

["C. M. Heard" <[e-mail]>]

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