[tsvwg] UDP Options - per segment or per datagram

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

On Mon, Jun 14, 2021 at 11:51 AM Joseph Touch  wrote:

> On Mon, Jun 14, 2021 at 11:14 AM C. M. Heard wrote:
>
>> On Mon, Jun 14, 2021 at 10:17 AM Joe Touch wrote:
>>
>>> Yes, but we still need the fraglen field in the last frag too.
>>>
>>
>> No, it is not necessary, if every option precedes the FRAG header.
>>
>> See the format I posted this am.
>>>
>>
>> I did read it. If I correctly understand what you wrote, there is an
>> underlying ASSUMPTION that options that apply per-fragment need to precede
>> the FRAG header and those that apply to the reassembled datagram have to
>> appear afterward. To be clear, I do not dispute that such a design will
>> work; it will. What I dispute is that it is necessary.
>>
>> In the design that I presented earlier, I also made an implicit
>> assumption that whether an option applies to an individual fragment or to
>> the reassembled datagram can be determined from the Option Kind (or UKind
>> or ExID). Going down the list:
>>
>> EOL - not applicable (FRAG consumes all trailing data)
>> NOP - per fragment
>> OCS - per fragment
>> ACS - per datagram
>> FRAG  - per fragment (obviously)
>> UNSAFE - depends on Ukind
>> TIME - per datagram
>> AE - per fragment (see below)
>> REQ, RES - per datagram
>> EXP - depends on UDP ExID
>>
>
> First, you can’t go down a list that includes options to be defined,
> unless we further fracture the option space into pre/post reassembly.
>

What I had in mind was that the definition of each option that the higher
layer could request would specify whether it applied to the entire
reassembled datagram (thus appearing only in the terminal fragment) or to
each individual fragment (thus appearing in each). Options that are
produced and consumed entirely at the transport layer would be per-fragment.

Logically, this is similar to the IPv4 Copied on Fragmentation flag, which
is specified for each IPv4 option, but with two important differences:

1. Since there is no such thing as in-flight UDP fragmentation -- it occurs
only at the source -- there is no need for the fragmentation engine to
worry about options it does not understand; the higher layer simply cannot
request these options.

2. In IPv4 EOL and NOP are not copied on fragmentation, but they also
cannot be explicitly requested by the higher layer. They exist solely for
the convenience of the layer where they are used. On transmit, they are
inserted as needed; on receive, they are consumed. These options can appear
in any fragment, but they do not make their way to the higher layer layer
with the payload of the received datagram.

In the cases -- rare, IMO -- where either behavior would be appropriate, it
can be distinguished by Option Kind or UKind.

Second, many of the examples you give as “known” are not:
> NOP can be needed for padding in either place.
> UNSAFE can’t be known in advance
> TIME can be per frag (for path RTT) or per segment (aggregate delay)
> REQ/RES can be either as well.
> AE for sure - it’s a trade between per-fragment safety and per-datagram
> efficiency
>

I think I explained NOP and EOL. I already said that the behavior of any
UNSAFE options would depend on UKIND, i.e., the definition of the
particular unsafe option would state whether it applies per-datagram or
per-fragment.

If TIME can be requested by the upper layer, what is the meaning if the
option is requested for a datagram that gets split into multiple fragments,
and the option is replicated in every fragment? I can see the per-fragment
argument but only when the option is produced and consumed at the UDP layer
-- as is the case for the corresponding TCP option (which appears on every
segment if it is negotiated). If it's intended to be produced and consumed
by the higher layer, it should be per-datagram.

The REQ and RES options exist for the benefit of DPLPMTUD and are intended
to be sent on a PLPMTU Probe Packet, which itself must not be further
fragmented (the probe packet will not serve its purpose if it is fragmented
to make it get to its destination). Ideally, these options are used on
packets with padding only and no user data; such packets would be generated
and consumed entirely within the transport layer or a shim. As they are not
subject to fragmentation, they can be considered complete datagrams. In
addition, it seems to me that there is little or no value in taking a REQ
option from the user and replicating it on every fragment of a datagram
that needs to be fragmented; this causes duplicate REQ tokens. Gorry, any
thoughts? (*)

AE (now AUTH and ENCR, as of -13) can protect  (AUTH) or depend on (ENCR)
all the options, if so configured. Certainly in that case it needs to be
per segment. It's possible to specify per-datagram versions -- possibly
including only per-datagram options, in some normalized form after
reassembly -- but this seriously complicates the specification. Do you
really want to do that?

(*) As an aside I see that draft-fairhurst-tsvwg-udp-options-dplpmtud-04
allows one packet contain RES options for multiple REQ datagrams; this
currently is not allowed in draft-ietf-tsvwg-udp-options-13:

   >> Except for NOP, each option SHOULD NOT occur more than once in a
   single UDP datagram. If an option other than NOP occurs more than
   once, a receiver MUST interpret only the first instance of that
   option and MUST ignore all others.


This is an inconsistency that needs to be resolved.

Mike Heard