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

[Joseph Touch <[e-mail]>]

Hi, Tom,

> On Jul 20, 2021, at 7:49 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Mon, Jul 19, 2021 at 5:58 PM Joe Touch <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Jul 19, 2021, at 3:11 PM, Tom Herbert <[e-mail]> wrote:
>>> 
>>> Please check the list archives, I have been pointing out the problems and deployment impediments with protocol trailers and for a while.
>> 
>> You have. I though you were limiting your comments to fragments at this time.
>> 
>>> Neither, AFAIK, has consensus been established on this.
>> 
>> It has never been consensus to limit use to only fragment mode. In fact, that mode has been argued as optional most recently.
>> 
> Limiting use to fragment mode is not what I am suggesting. There are
> applications that need legacy mode and those that don't (DNS on the
> Internet needs it, UDP tunnels in a datacenter don't). There are
> implementations that support protocol trailers and those that don't
> (like the routers I mentioned). Protocol trailers are technically
> required in legacy mode, but there is no technical rationale why
> non-legacy mode needs trailers. 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. For instance, UDP
> options is a means to bring extensibility to otherwise non-extensible
> UDP encapsulation protocols and augmenting VXLAN with a fragmentation
> capability is compelling. But if protocol trailers are a forced
> requirement, then I believe that would preclude us from ever using UDP
> options with UDP encapsulation-- that would be unfortunate.

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.

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

Joe