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

[Tom Herbert <[e-mail]>]

On Sat, Aug 12, 2023 at 6:14 PM C. M. Heard <[e-mail]> wrote:
>
> On Fri, Aug 11, 2023 at 7:47 PM Joe Touch wrote:
>>
>> Just to be clear:
>>
>> On Aug 11, 2023, at 2:42 PM, C. M. Heard <[e-mail]> wrote:
>>>
>>> I've been pushing the idea to co-opt the per-fragment UDP options used for host-to-network signaling, and I'd like to make some comments about that.
>>
>>
>> This confuses transport options with network options.
>
>
> Not confusion, but rather an explicit proposal to use the per-fragment options as network options instead of transport options. It is put forward to provide potentially workable solutions to the problems that draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal are intended to solve.
>
> Granted, an architecturally preferable way to accomplish these objectives would be to use IPv4 Options or IPv6 Hop-by-Hop Options. Indeed, I myself would prefer for IPv4/IPv6 Options to be used if the issues of high discard rates of packets with these options could be solved. There are efforts underway to mitigate the problems for IPv6 Hop-by-Hop Options. Those might bear fruit someday, though the timeline is at best uncertain. But as far as I know, the discard rates for IPv4 Options are equally dismal, and there are no efforts underway to fix that problem. Correction by parties with better knowledge of the facts than mine are invited.
>
> My take is that the problems that draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal (and possibly draft-daiya-tsvwg-udp-options-protocol-number as well) could, in principle, be solved by what I see as a modest change of direction to the UDP Options spec. Whether that would work out in practice is much less certain, for the reasons that Tom Herbert has pointed out. IMO it is a judgement call whether the chances are better to get IP Options (in any version) to work within our professional lifetimes. Given that, I don't think it would be right to turn draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal away without a proper discussion.
>

Mike,

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.

I believe the requirements for a network layer protocol are something like:

1) Be able to encapsulate any transport protocol.

In the case of UDP there are already several protocols that do this:
SCTP over UDP, GRE over UDP, MPLS over UDP. The one critical transport
protocol that is yet to be supported in UDP is TCP (I have posted
tcp-in-udp draft for this)

2) A network protocol is processed by intermediate nodes in the path,
not just end points; processing at intermediate nodes must therefore
be robust.

It is going to be difficult for a UDP protocol to fully satisfy this
requirement. There are no code points in the UDP header that can be
used by intermediate nodes without the risk of misinterpretation. Port
numbers can only be correctly interpreted by the endpoints (RFC7605),
and the existence of a surplus area, even in the case UDP length==8,
does not imply 100% probability that the surplus area contains UDP
Options. So processing of UDP at intermediate nodes as a network layer
is at best "probabilistically robust". Magic numbers and checksum can
reduce the probability of misinterpretation to something close, but
not equal, to 0%. To contrast, IPv6 has sufficient code points such
that if an IPv6 packet is received and the next protocol is 0, then
the packet *contains* Hop-by-Hop options (lest the packet is corrupted
or the sender sent a malformed, non-conformant packet)-- so IPv6 and
IPv4 protocols, are fully robust in this regard

3) A network protocol should be extensible with options.

It is conceivable that the UDP surplus could contain network options.

4) A network protocol should allow some network options to be modified in flight

A general mechanism for network options would include the ability to
modify data in flight. This is handled in Hop-by-Hop options with a
bit that indicates rather intermediate nodes can modify data in
flight. Functionally, this is possible in UDP options assuming that
the options aren't encrypted or authenticated; when data is modified
in flight the OCS would need to be adjusted accordingly to keep it
correct

Since packets are being modified in flight, misinterpretation as
described in #2 could lead to systematic data corruption which would
be really bad! So we need the mechanisms defined to make
misinterpretation extremely unlikely.

5) Processing a network protocol must be efficient

The network protocol must be in packet headers and not trailers since
its unlikely intermediate nodes can efficiently process trailers.
Also, there must be considerations for slow path versus fast path
processing, and DoS mitigations. For Hop-by-Hop options these are
discussed in draft-ietf-6man-hbh-processing and
draft-ietf-6man-eh-limits. Network options in UDP would essentially be
Hop-by-Hop options just packaged differently, so I believe the drafts
and other lessons we've learned in dealing with network options are
applicable.


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

Tom


> Thanks,
>
> Mike