Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[Joseph Touch <[e-mail]>]

Hi, Tom,

There’s no debating that zero-copy networking is challenging - moreso when dealing with an OS that is “different for the sake of being different” (Linux, largely for copyright reasons).

To your points:
> 
> IMO, if you want to make UDP options seamlessly integrate and get
> ubiquitous support of UDP options in the OS and hardware (leverage
> checksum offload, zero copy, hardware fragmentation/reassembly,
> offload authentication/crypto, header/data split, etc.),

Seamlessness is not a goal; we want only to not get in the way.

> the best
> direction would be to make UDP with options look like TCP as much as
> possible at least with regards to packet format.

QUIC doesn’t and UDP can’t.

> i.e. use the same
> option format, have a header length field, use headers instead of
> trailers, etc.

We do use the same basic format (TLV). We do have a length field where it would help zero-copy (FRAG), but not elsewhere. 

And we do use headers for FRAG but not elsewhere.

Again, this is UDP. We can’t redefine it in a way that lets incorrect data be received at legacy endpoints.

And - this is key - we also do not want to make the mistakes TCP made, even if that makes UDP options require its own code. E.g., we don’t want to limit UDP header length to 40 bytes.

So the best we can do (and are doing) is *enable* new code for UDP zero-copy. For FRAG, that means putting the length where it can be found without TLV-chain parsing. But a true UDP zero-copy stack that supports non-frag messages would need to know how to deal with trailers rather than headers.

And, FWIW, trailers are just as easy if not *EASIER* for zero-copy to handle; they just DMA the user data first then the UDP options.

Joe