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

["C. M. Heard" <[e-mail]>]

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.

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
<https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg>.

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

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