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

[Tom Herbert <[e-mail]>]

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.

> I have already put one proposal on the table that divorces FRAG from LITE.
> See the thread UDP Options: how to do FRAG without LITE and forced UDP CS=0.
>
> I recently put forward a better proposal, based on a variant of Tom Herbert.s header.
> It's at the end of https://mailarchive.ietf.org/arch/msg/tsvwg/XZxL29UA-95ReA72mxv5-kEytK0
>
> Derek Fawcus suggested a further improvement that will also support LITE.
> It's available at https://mailarchive.ietf.org/arch/msg/tsvwg/jqctei-uuocYIp1qTJ0p1mIE-HI
>
That mentions support for checksum coverage like in UDP-Lite. I would
suggest support for that is not a requirement. Host systems perform
much better processing whole packet checksums than partial checksums
(one reason why UDP-Lite never got any traction). Also, for UDP
checksum compensation to work the checksum has to cover the whole
surplus space.

> I'll post a message fleshing out Derek's ideas but I'll use the other thread for that.
>
> Getting back to this thread and the core design assumptions that Joe posted:
>
>> 1- support options
>> 2- allow at least some options to be silently ignored by legacy receivers (to enable ‘“optionally enhanced” exchanges)
>> 3- allow at least some options to be required
>> 4- allow the options themselves to be protected
>> 5- support for fragmentation/reassembly
>> 6- support for MTU discovery
>> 7- support (optional?) middlebox checksum/payload length bug traversal
>> 8- support LITE, i.e., where some of the payload is not covered by at least some checksum processing
>
>
> Modulo clarification of  #3, I agree with that list. But I would also add:
>
> 9 - any option that affects the handling of payload data must share fate with that payload data, by all receivers (legacy or otherwise)
>
> The clarification to #3 that I would like to see is whether "required" means:
> (a) "required for any conforming implementation to support" or
> (b) "required by the receiver in every packet"
>
> I ask because the term is used both ways in draft-ietf-tsvwg-udp-options-07.
>
> Either way, I think everything on the list is achievable.
>
> Thanks & regards,
>
> Mike