Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

Hi, Derek,

On 2019-07-16 14:52, Derek Fawcus wrote: 

> On Tue, Jul 16, 2019 at 10:04:24PM +0100, Derek Fawcus wrote: 
> 
>> I need to draw some pictures to work things out, and also consider the
>> FRAG implications, but I'm sort of liking the general direction
>> of Mike's suggestions in this sub thread.
> 
> Something that is percolating, and I need to try to flesh out:
> 
> If we take Mikes suggestion of the herbert framing, but with a
> 16 bit length field, also a fixed position checksum.

First, let's skip the type field, i.e., at best add the length field to
udp-opt. We really don't need "classes" of option approaches... 

> Then
> treat the length as a "checksum coverage" field ala UDP-Lite.
> Also reintroduce the CCO option, and retain the "End of Options" option.

That seems like too much and I'm not sure we need the length field in
every packet. 

E.g., if we have EOL, we don't need length. Either one suffices. 

> We then declare that the coverage always has to include all
> options.
> 
> So in the absense of LITE data, the coverage will always amount
> to the total length of the surplus, and the CCO option does
> not need to be present.  We can use the "End of options" to
> mark where normal payload data starts, where such data experiences
> the "fate sharing" Mike was discussing.

Agreed, but somehow it has to be easy to figure out when NOT to bother
having the receiver check OCS on the full received surplus area quickly.


> If the coverage is less than that surplus length, then the sender
> should include the CCO option (to compensate for middleboxes),
> but the receiver can simply ignore it.  Any data beyond the
> coverage length is LITE data.  If we ever get the middlebox fixed
> (or following dynamic path probing), one could omit sending the
> CCO option.

I like that... 

> Would we still need a LITE option?  Would we have any desire to
> handle fragmented LITE data?  If we were to send fragmented
> LITE data, then a LITE option may be useful as a specialised
> LITE-FRAG option.

I hope we can still find a way to make these possible - even "at your
own risk". 

> We should probably recommend not sending both legacy UDP payload
> data at the same time as surplus area none-LITE payload data.

Yes, but that should never be meaningful. It would end up sending
duplicate data to option-aware receivers. 

I.e., of all the things options do, they DO NOT REDEFINE the existing
UDP data area. 

Joe