Re: [tsvwg] design assumptions - draft-ietf-udp-options

[Tom Herbert <[e-mail]>]

On Wed, Jul 17, 2019 at 12:45 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-17 12:30, Tom Herbert wrote:
>
> On Wed, Jul 17, 2019 at 12:16 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
> ... Thus the LITE option isn't needed and the awkward moving
> around user data to reconstruct the protocol trailer is unneeded.
>
>
> There were two reasons for the swaps involved:
>
> 1) to enable support for zero-copy (if we're optimizing for any sort of processing, it ought to be this sort of endpoint issue)
>
> That's not needed for zero copy. We already understand how to handle
> an optimize variable length headers with options such as TCP. Trailers
> do not help that, and in fact they make efficient implemenation much
> harder.
>
>
> When the UDP packet arrives, as it comes in the door, where do you put the data? Remember, you get to put it somewhere ONCE.
>
> With trailers and the existing approach, you can swap a few bytes and chop off the end just fine. With headers, not so much.
>
In the _existing_ approach, any reasonably modern stack has a data
point in packet metadtata (in mbufs, mblock, skbuffs, etc.). The data
pointer that moves as the headers as they are processed and eventually
the data pointer points to the user data that can be copied out,
memory mapped, etc.-- there's no byte swapping. This is shown in
prototype implementation of UDP Extended Header in
https://mailarchive.ietf.org/arch/msg/tsvwg/ZwIwOQKtbM_xXIQ3oC9Vc0mguB8.

But let's assume for a second that you've discovered something new and
protocol trailers are significant implementation improvement. Great!
You're going to need to _prove_ that though. That means you need to
write a real implementation, test it, have peer review. In other
works, you need to show your work. Frankly, academic speculation about
implementation is pointless, we need to see the code it you want to
prove your point.

>
>
> 2) to allow fragments to have both per-fragment options as well as options over the reassembled whole; this is important to provide both CCO (per fragment) and AE (over the whole result). And no, doing security, integrity checks, etc., on fragments is not the same as doing it over the reassembled whole.
>
>
> That is also not needed. In both IPv4 and IPv6 fragmentation, the
> options (extension headers) that are set in the reassembled packet are
> taken from the first packet. The same approach can be taken in UDP
> options.
>
>
> No, they can't - exactly as you now note:
>
Works for IPv4 and IPv6...

>
> As for security and integrity checks being different on fragments than
> a whole packet, that is true-- those are going to be much more costly
> for operations. For instance, we can easily offload a per packet
> checksum to hardware, but not the reassembly checksum. That's
> potentially a big performance hit for no value.
>
>
> By "no value" see "End to End Arguments in System Design".
>
> Joe