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

[Joseph Touch <[e-mail]>]

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] <mailto:[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.

If you’re looking for a successful version of trailers, perhaps Ethernet will convince you? How about HTTP since 1.1? HLDC and PPP?


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

> 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

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.

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

Joe