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

[Joe Touch <[e-mail]>]

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. 

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

> 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