Re: [tsvwg] Alternative version of the UDP FRAG option

[Joe Touch <[e-mail]>]

> On Mar 18, 2019, at 7:32 PM, Tom Herbert <[e-mail]> wrote:
> ...
> 
> There's no guarantee between consecutive packets in UDP that the destination is the same host.

This is an Internet protocol, which means that it is the responsibility of the hosts that share a single IP address to act as one - not the responsibility of a protocol to overcome that challenge if not supported.

Soft state accomplishes this; the idea is to only do things that you think the other end can tolerate, with the expectation that nothing severe should ever happen, regardless.

> Important options must always be sent in a format that legacy receivers drop. That is rule #1.

They’re in the surplus area; legacy receivers will ignore them, not “drop” the packets they arrive in. This is a known hazard of the LITE option; any receiver that counts packets (i.e., that interprets zero-length packets as having meaning) will be affected by the current proposal for LITE with a zero payload.  We’ve agreed to live with that, though.

> Rule #2 is that receivers must drop important options they don't understand.

Legacy receivers drop all options. There are no “important” options as you define them above; there are “mandatory to implement” options, i.e., if you speak UDP options you must speak those, but that’s it.

> That's simply addressed by the skip/drop bit in type.

A legacy receiver can already “skip all options” and accept a packet, so having a “drop” flag would have an unpredictable effect. What’s the point of that?

> Rule #3 is that important options need integrity check, hence a checksum.

There are no important UDP options, as noted above. 

> These rules are sufficient to meet the requirements without depending on an external control plane or configuration.

External configuration is always important anyway. Senders have to be configured to know what options to use on a given socket. It’s always a receiver’s prerogative to make requirements of received packets anyway. This is no different.

Joe