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

[Joe Touch <[e-mail]>]

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) 

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. 

Joe