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

[Derek Fawcus <[e-mail]>]

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

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.

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.

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.

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

DF