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

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

On Sun, Aug 13, 2023 at 8:49 AM Tom Herbert wrote:
> The possibility of using the UDP surplus area to convey network
> options merits discussion. This is really about exploring if UDP
> can be "the new network layer" as some have suggested.

Thank you.

[ ... much good discussion elided ... ]

> In short, I believe it possible to define network options in the
> UDP surplus area or UDP options, although I'm not sure this is only
> a modest change to the UDP options spec (maybe we need a draft on
> network options in UDP options?).

While a complete draft would certainly be preferable, let me start
with this sketch. It begins with a revised FRAG options, which
now includes a PROTOCOL number, more or less as proposed in
draft-daiya-tsvwg-udp-options-protocol-number:


     +-------------+------------+

     | Src Port    | Dst Port   |

     +-------------+------------+

     | UDP Len = 8 | UDP Chksum |

     +-------------+------------+

     |     OCS     |K=3  L=14/16|

     +-------------+------------+

     |      Identification      |

     +--------------------------+

     |  Protocol   | Frag. Off. |

     +-------------+------------+

  ,--| Frag. Start |   (RDOS)   |

  |  +-------------+------------+

  |  ~ Per Fragment Options     ~

  `->+-------------+------------+

     ~      Fragment Data       ~

     +-------------+------------+



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.

2.) All network options are per-fragment options; none reside in the
surplus area of the reassembled UDP datagram (indicated by RDOS).

3.) Transport options that apply to the entire reassembled UDP
datagram MUST reside in the surplus area of the reassembled UDP
datagram (indicated by RDOS).

4.) Some options, such as AUTH or UENC, might logically be construed
to apply either to a single fragment of the entire datagram. They
may appear as per-fragment options only if when they are actually
being used as network options intended for be interpreted by
intermediate systems. Otherwise, they MUST appear in the surplus
area of the reassembled UDP datagram (indicated by RDOS).

5.) The Identification field is to be interpreted in the context not
only of the source and destination UDP ports and source and destination
IP addresses, but also of the Protocol field.

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.

Note that it's possible to send atomic fragments by setting Frag.
Off. equal to zero and Option Length = 16 (indicating that the
RDOS -- or pre-fragmentation UDP length -- field is present). Thus,
there is no requirement to actually fragment a datagram except when
it won't fit within the path MTU. In effect, the FRAG option morphs
into something like the general-purpose UDP Surplus Header that
was proposed in draft-herbert-udp-space-hdr. The main difference is
that we do not require this option/header when only transport
options are used and no fragmentation is required. In particular,
draft-ietf-tsvwg-udp-options-dplpmtud required no changes at all.

This sketch does not fully address the robustness issue, though
IMO this is likely not a serious issue given that there are no known
uses of the UDP surplus area.

This sketch does not directly address the issue of modifiable
network options, though I think that it should be possible to deal
with that in individual option specifications. I need to think
about the need to recognize options as mutable or immutable without
detailed knowledge of the option. My understanding is that this was
needed in IPv6 primarily to accommodate AH.

This sketch does address the performance issue of intermediate
systems having to process trailers -- which would not work
anyway if UDP fragmentation is used.

I'm not sure that this sketch actually does a worse job than of
addressing the backward compatibility issue than does IPv6 HbH,
given that at the present time the empirical evidence suggests
that IPv6 HbH suppers a vastly worse drop rate than UDP packets
with a surplus area, though this last claim must be tempered by
lack of data on the specific case of UDP Length == 8. What I see
is a very long tail to full adoption for both, though operation of
UDP Options between consenting systems seems more likely to work
in the short to medium term.

This sketch definitely does a better job of supporting IPv4 than
does IPv6 HbH :-)

If there is sufficient interest, I will try to turn this sketch
into a proper proposal.

> But even if this is possible, I have to ask the question: Is it worth
> doing? Is this an elegant solution to a fundamental problem on the
> Internet, or is it a hack that is trading one set of problems related
> to Hop-by-Hop options for another set of problems? Five years from now
> will we still be grappling with how to host to network signaling on
> the Internet despite a lot of effort to make a UDP solution work, or
> will we see this as a solved problem with wide scale deployment?

That, indeed, is the question. I hope we can converge soon enough to
ship UDP Options fairly soon.

Mike Heard