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

[Tom Herbert <[e-mail]>]

On Sun, Aug 20, 2023 at 2:32 PM C. M. Heard <[e-mail]> wrote:
>
> 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.

Mike,

The problem we're facing is that the UDP Options draft defines the
whole surplus area to be transport options; it's not extensible to
carry network options or other protocols we might dream of. There is
an easy way to make the surplus area extensible: define a type field
in the surplus area header. To enable the possibility of using header
chains in the surplus area we need a header length in the surplus area
as well. These two fields along with the checksum are the fields for a
surplus area header that I proposed in draft-herbert-udp-space-hdr.
Adding them would be a fairly minor change to the UDP Options draft; a
type number for UDP Options would need to be defined, the aggregate
length of the options would be set in the length field, but otherwise
it doesn't affect anything in the rest of the draft. Once
extensibility is enabled in the surplus area, the protocol for network
options in the surplus area could be independently developed without
impeding progress on finishing UDP transport options.

Tom

>
> Thanks and regards.
>
> Mike Heard
>