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

[Tom Herbert <[e-mail]>]

On Sat, Jul 31, 2021 at 10:33 AM Joseph Touch <[e-mail]> wrote:
>
>
>
> > On Jul 31, 2021, at 10:17 AM, Tom Herbert <[e-mail]> wrote:
> >
> > 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.
>
> They’re not separable. If you can’t support non-legacy, you don’t support UDP options.
>
> This has never been a “pick and choose” spec.
>
> >> 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.
>
> It doesn’t benefit or hinder hardware implementation. It affects queuing delay in either case, but that’s not an issue for an endpoint protocol like UDP.
>
> > 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.
>
> And if we were designing one from scratch, I would agree.
>
> > Implementations have assumed this convention, and
> > introducing a protocol that goes against this convention will have
> > adverse effects.
>
> We don’t have a choice for legacy mode.
>
> > The effects could be loss of performance or
> > functionality, or outright complete inability to support the protocol.
>
> Performance, yes. But by your own admission, the TLV is likely to be processed in software (wherever that is) anyway.
>
> >> 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.
>
> The result of a “pick and choose” protocol is the same, if not worse.
>
> Again, like most of the IETF, we’re focusing on ubiquity over performance.
>
> >> 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.
>
> I was giving your approach the benefit of the doubt that the software could be updated to support legacy acceleration hardware.
>
> If that can’t happen, then UDP options can’t be supported because they aren’t right now.
>
> > 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.
>
> Right. But you CAN just have it push the whole reassembled packet with trailers to the OS and let the OS software handle the rest - just like it would need to for legacy mode anyway.
>
> > 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.
>
> Agreed - which is even LESS reason to try to optimize for today’s 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.
> >>
> > 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.
>
> How does leaving legacy endpoints out “support as many users as possible” vs. merely using software to complement hardware acceleration, the latter which would support all users?

Joe,

You seem to be missing my point. There are implementations that
terminate UDP and CANNOT process protocol trailers; this is not just
an inconvenient performance degradation. Yes, that means that they
can't use legacy mode, but I don't see the technical argument that UDP
couldn't be productively supported by these implementations if UDP
options are all contained in headers. I do not believe this is an
aberration, we know for instance there are HW routers terminating UDP
tunnels, and it would be a delusion to believe these implementations
could be fixed to support protocol trailers in a finite time. So if
protocol trailers are a forced requirement, even in non-legacy mode
which is what tunnels would use anyway since they're configured, it
seems like we're excluding use cases such as UDP tunnels where UDP
options might be compelling. Given this, what is your answer to
someone who wants to use UDP options with UDP tunnels?

Tom

>
> Joe