Re: [tsvwg] UDP options and header-data split (zero copy)

[Tom Herbert <[e-mail]>]

On Sat, Jul 31, 2021 at 9:18 AM Joseph Touch <[e-mail]> wrote:
>
> Hi, Tom,
>
> On Jul 31, 2021, at 7:53 AM, Tom Herbert <[e-mail]> wrote:
>
> On Fri, Jul 30, 2021 at 8:35 PM Joseph Touch <[e-mail]> wrote:
>
>
> Hi, Tom,
>
> On Jul 20, 2021, at 7:49 AM, Tom Herbert <[e-mail]> wrote:
> ...
> Limiting use to fragment mode is not what I am suggesting.
>
>  ...If trailers are required in all use
> cases, then devices that don't support them can't use UDP options even
> if they're only interested in non-legacy mode uses
>
> ….
>
>
> I don’t follow this line of logic.
>
> You claim that you’re not limiting use to frag-only, but then talk about “if trailers are required”.
>
> There’s no IF. They are.
>
>
> Joe,
>
> That is an opinion, not an established fact.
>
>
> Trailers have been shown to be the only way to support legacy mode use of UDP options. Nobody else has ever suggested or accepted that legacy mode is an optional part of this spec.
>
> If you want to convince
> us that trailers are a requirement in all use cases, specifically
> non-legacy mode, then please provide at least one example of options
> that could not be correctly conveyed in protocol headers.
>
>
> Legacy mode.
>
> Given that
> we have many examples of successful protocols that have protocol
> options in headers, IP options, TCP options, and IPv6 which provides
> the example of how per fragment options and options for the
> reassembled packet, I am dubious the need for trailers can be proven.
>
>
> We’ve already done so for legacy mode.
>
But not for non-legacy mode.

> If you’re looking for a successful version of trailers, perhaps Ethernet will convince you? How about HTTP since 1.1? HLDC and PPP?
>
No, it's not convincing. HTTP is an application layer protocol.
Ethernet, HDLC, and PPP are layer 2 protocols that have headers and
use trailers for only FCS and CRC for the benefit of hardware
implementation. You could also add ESP to this list which again
primarily uses a header and puts authentication data. These are not
comparable to UDP options which is an open ended list of TLVs which is
more likely to be processed in software. For network layer and
transport layer protocols, protocol headers are the longstanding
convention. Implementations have assumed this convention, and
introducing a protocol that goes against this convention will have
adverse effects. The effects could be loss of performance or
functionality, or outright complete inability to support the protocol.

>
> If an implementation can’t deal with trailers, it can’t support UDP options - the core set is “all or none”, not “pick what you want”.
>
>
> If an implementation can't deal with trailers, then that means that
> users of those implementations can't use UDP options.
>
>
> Again, that IS the point.

I don't see how that isn't arbitrarily and knowingly eliminating the
number of users and use cases for the protocol.

>
> If users can[’t] use
> the protocol we're defining then what is the point of bringing it to
> IETF?
>
>
> (I’m presuming you meant “can’t” above)
>
> We have two types of legacy users:
> - legacy UDP endpoints in general
> - updatable endpoints with legacy UDP acceleration hardware
>
What does "updatable" mean. If there is some piece of hardware that
doesn't support protocol trailers, it's not like we can just call up
the vendor and they'll fix it in a month. Fixing hardware takes years,
and that assumes the vendors see any business value to invest in the
fix which only exists if UDP options use becomes prevalent and support
is being demanded by customers.

> Your claim is that we can’t support both groups, especially if they interact.Even if we were to accept your claim, we would always choose to support legacy endpoints in general. If we have to sacrifice, we should sacrifice performance to maintain interoperability.
>
To the contrary, my claim is that we need to support as many users as
possible. Avoiding a requirement for protocol trailers aligns with
that goal, requiring protocol trailers opposes that goal and limits
the number of users that can use the protocol.

Tom

> That decision is not unique to UDP or UDP options; it is the approach used throughout the IETF.
>
> Joe
>