Re: [tsvwg] signaling packet importance [was Re: New Version Notification for draft-herbert-fast]

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

On Sun, Aug 20, 2023 at 9:12 AM Tom Herbert wrote:
>
> Hi Mike,
>
> Thanks for the outline. Comments inline.
>

Thank you for the comments. There are a couple of clarifications
that I'd like to make, then I'll close with some general comments
aimed mainly at the authors of the three drafts.

[ ... proposed mod to FRAG header clipped ... ]

> > The updated rules would be:
> >
> > 1.) The FRAG option, if it appears at all, MUST appear immediately
> > after OCS in a packet with UDP Length == 8. If it appears anywhere
> > else, the option area is malformed and MUST be discarded.
>
> I assume you mean the packet MUST be discarded?

No, just the options, though if UDP Length == 8, that amounts to the
same thing. If the FRAG option appears in amn options trailer, a
legacy receiver will ignore the options and accept the data (assuming
its checksum is good). The rule above is changed from the current
draft only to the extent of REQUIRING the FRAG header to appear as
the first option after OCS; the current spec RECOMMENDS that.

> > 6.) If the Protocol field is not recognized, end systems MUST
> > discard the packet outright without further processing. In the
> > initial specification of UDP Options, a distinguished value (e.g.,
> > 0x0000 of 0xFFFF) indicates that the reassembled packet is an
> > ordinary UDP datagram. Other values will be specified in future
> > specifications. This rule allows the fragment data area to be
> > interpreted differently for different Protocol numbers, in
> > effect treating the Protocol number as a Next Header number.
> >
>
> I don't understand the purpose of this field or why it would need to
> be sixteen bits. Is this intended to be an EtherType so that this is
> another type of UDP encapsulation?

It was intended to work much like the Next Header field in your
UDP Surplus Header proposal, and I made it 16 bits in deference to
draft-daiya-tsvwg-udp-options-protocol-number -- which, probably not
coincidentally, calls it Next Header Number in Figure 1 of the draft.
See also draft-touch-tcpm-sno (now expired). I had intended to say
this in the email, sorry for the omission.

> Identification, Frag. off, and Frag. start (16 bytes I believe)
> become unnecessary overhead [in atomic fragments].

8 bytes, but yes, unnecessary overhead for an important use case.

[ ... proposal based on draft-herbert-udp-space-hdr elided ... ]

> I know that this is suggesting a big change relative to the current
> UDP Options draft, but I will point out most of these ideas have
> already been brought up and I'm not particularly advocating this
> direction. But, I do believe that if the UDP surplus area is to carry
> network options we need to design explicitly for that, especially if
> we want any chance to pass the five year test I mentioned.

Indeed, draft-herbert-udp-space-hdr appeared in 2019, but the ideas
therein did not catch on at that time, I think because the focus was
on transport options. It was not until about two years later
(draft-ietf-tsvwg-udp-options-13, June 2021) that per-fragment
options immediately following the FRAG header were fully specified.
This (inadvertently) made host-to-network signaling practical,
although though this use was, and still is, explicitly disavowed by
the UDP Options specification (note the section entitled "UDP Options
are for Transport, Not Transit").

As of IETF 117, there were five drafts that refer normatively to
draft-ietf-tsvwg-udp-options.

One, draft-ietf-tsvwg-udp-options-dplpmtud, specifies how to use UDP
Options to implement DLPMTUD. This is a safe end-to-end use use of
transport options, where "safe" means that a receiver that does not
implement UDP Options will still be able to correctly interpret the
UDP data that is transferred, though DLPMTUD won't work.

Another, draft-ietf-opsawg-tsvwg-udp-ipfix, specifies new IPFIX
Information Elements for UDP options. It is agnostic to the question
of whether those options are network options or transport options.

A third, draft-daiya-tsvwg-udp-options-protocol-number, proposes
a protocol number option to specify the protocol immediately following
the UDP header. "Immediately following" refers either to a datagram
that is transmitted without the use of the UDP FRAG option, or to a
UDP datagram after reassembly, if the FRAG option is used. This clearly
qualifies as a transport option, but if the receiving endpoint needs
the option to correctly interpret the UDP payload, as suggested in
Section 3.2, the option number needs to be in the UNSAFE range, and
then the option can appear only behind a FRAG option (or whatever might
take its place if the ideas in draft-herbert-udp-space-hdr take hold).
Additionally, there may be other uses of the protocol number as a next
header number, as suggested above, to identify other protocols
"sandwiched" between the UDP header and the transport payload.

The final two, draft-kaippallimalil-tsvwg-media-hdr-wireless and
draft-reddy-tsvwg-explcit-signal, explicitly propose network options
intended for host-to-network signaling. Both Tom and I argue that
such signals will not be viable if buried in an options trailer if
the devices that consume them have limited visibility into the payload
of transit packets. I think we may have convinced Dan Wing -- I'm not
sure -- but we have not heard from the other authors. If some or all
of you disagree with this point, please say so and say why. I do think
that if we are going to support these use cases in UDP Options, the
solution needs to be workable and  comprehensive. While Tom and I may
argue about the details, I think we are firmly in agreement on that.

So the first and biggest question that we (as a WG) need to answer is
whether we do or do not want to increase the scope of the specification
to include network options. The details of how to accomplish that,
while important, are secondary. If we decide not to go in that
direction, I think that we should continue to work through the issues
list (https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues)
and try to get an acceptable transport options specification shipped
sooner rather than later.

Thanks and regards.

Mike Heard