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

[Tom Herbert <[e-mail]>]

On Wed, Jul 17, 2019 at 12:16 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-17 12:02, Tom Herbert wrote:
>
> On Wed, Jul 17, 2019 at 11:20 AM C. M. Heard <[e-mail]> wrote:
>
>
> On Wed, Jul 17, 2019 at 10:14 AM Black, David <[e-mail]> wrote:
>
>
> Joe,
>
> Still as an individual ..
>
> I would agree with your point on #8 LITE were it not that #8 is the basis for
> the only way we have to accomplish #5 Frag while satisfying #2.
>
>
>
> I emphatically disagree that LITE is needed to support FRAG in an acceptable way.
>
> +1
>
> The requirement when there are UDP options that can't be ignored, like
> FRAG, is that the UDP length is eight and so all the protocol and user
> data is in the surplus. The bits in the surplus area can be arranged
> as convenient, so then the UDP options can be in a header as opposed
> to trailer. 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.

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

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.

Tom


>
> Joe