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

[Tom Herbert <[e-mail]>]

Hi Mike,

Thanks for the outline. Comments inline.

On Sat, Aug 19, 2023 at 8:34 PM C. M. Heard <[e-mail]> wrote:
>
> 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.

I assume you mean the packet 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.
>

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?

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

Yes, but network options are independent of fragmentation, and in
many, if not most use cases, atomic fragments would be the norm
(neither QUIC nor TCP use IP fragmentation for example, but might want
to use network options). The problem with that is that Identification,
Frag. off, and Frag. start (16 bytes I believe) become unnecessary
overhead. I imagine this is why the IPv4 header had fragmentation
fields, but IPv6 moved fragmentation to an extension header so that
the IPv6 header doesn't have the overhead tax.

> 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.
>
Since there's no codepoint, any solution for using UDP as the new
network layer can only be "probabilistically robust", so "likely not a
serious issue" is an unquantified statement of probability. Assessing
the risk involves two parts: 1) the probability of the event happening
2) the possible harm that might be done when the event occurs.

For the first part, the OCS is used as "The primary purpose of the OCS
is used in UDP Options to detect non-standard (i.e., non-option) uses
of that area and accidental errors". The probability of a checksum
appearing being correct for data that is not UDP Options is
quantifiable (that of course assumes the checksum is non-zero). The
problem I see is that validating a checksum is fairly expensive and
proportional to the amount of data covered by a checksum-- this might
be prohibitive on high performance network devices (why RFC6936 was
written). An alternative is to use a magic number (like PLUS had); the
probability of a magic number matching data that is not UDP Options is
quantifiable and verifying a magic number is a lot less work.

For the second part, we can consider whether the options are read only
or modifiable. If they're read only then it's a question of what the
worst effect can be for misinterpretation. In UDP Options, this is
already indicated by UNSAFE and SAFE options. Presumably, the network
options and per fragment options could all be effectively safe
options. Modifiable options are a different story. If an intermediate
node were to misinterpret a packet as have UDP options and then modify
the options, then that is a data corruption. That is very bad! If this
happens it's not a bug in the implementation or configuration, it is a
protocol bug that could be very difficult to identify and work around.
If modifiable network options are allowed as suggested below then
there should be strong mechanisms in place to prevent
misinterpretation.

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

More generally it's just needed to identify which options are allowed
to be modified.

If network options are allowed to be modified by an intermediate node
then the OCS will need to be updated (presumably, the intermediate
node validates the OCS or a magic number is present).

I mentioned the risks of modifying network options in the case of
misinterpretation above.

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

I disagree with that :-). At best this is speculation. Hop-by-Hop are
supported by every major OS, they're defined by an Internet Standard,
and IPv6 HbH is already being productively used in deployments for
IOAM. These deployments in limited domains which is the primary use
case of network options. The high loss rates reported for Hop-by-Hop
Options on the Internet doesn't mean their entirely unusable

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

Maybe, but that's still speculation. Also, draft-herbert-ipv4-eh
defines a means to use extension headers with IPv4.

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

Personally, I don't have a strong opinion-- this might have value,
however I think it will take a lot of work to really do it right.
There's an obvious motivation to try to add UDP Options to network
options with the minimal changes to the UDP Options draft, however,
colloquially speaking, I think this might be trying to shoehorn
network options into UDP Options. It's entirely possible that network
options could become the primary use case of UDP surplus area (as the
"new network layer") given that we're seeing more proposals to use UDP
Options as network options than transport options, and the use cases
for UDP transport options seem quite limited (QUIC doesn't need them
and TCP-in-UDP wouldn't either). Since UDP Options haven't been
published and we haven't formally to the format of the surplus area
bits, there is still an opportunity to design network options in the
UDP surplus area with first class support.

Consider that if the surplus area were to contain a header chain this
would address a lot of the issues and provide for extensibility. The
surplus area when UDP Length=8 could be composed of a primary header
like that defined draft-herbert-udp-space-hdr. The primary header
includes a type which is either a number for an extension header or 59
to indicate the end of the header chain (data immediately follows).
Hop-by-Hop Options, Destination Options, Fragment Header, Auth header,
Ecap Header are all potentially useful. For example, the use of the
Fragment Header eliminates the overhead in atomic fragments. If the
Fragment Header is defined to be the same as the IPv6 Frag Header then
we can reuse the existing protocol and implementation. In fact, if we
reuse the existing extension header protocols where possible this
substantially reduces protocol development and promotes code reuse in
implementation. Transport options could also be an extension header in
the chain. This clearly separates network options from transport
options, and has the advantage of keeping the transport options in
headers which can be more efficiently processed by the host (I've
mentioned this before and the feedback was that the transport options
should be in trailers to align with the use case where UDP Length != 8
and the options must be in trailers; IMO trailers are the anomaly
here, if we can keep options in headers for UDP Length=8 then this is
consistent with pretty much all network and transport layer
protocols).

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.

Tom

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