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

[Joe Touch <[e-mail]>]

> 

On 2019-07-15 16:14, Tom Herbert wrote:

> On Mon, Jul 15, 2019 at 3:01 PM Joe Touch <[e-mail]> wrote: 
> 
>> ...
>> 
>> However, header/trailer is a misnomer. It's really about whether and how much to use LITE.
> I disagree. We have at least thirty years experience with protocol
> _headers_ on the Internet.

That doesn't stop every solution for UDP from being a "trailer". 

They either trail conventional UDP data or zero-length UDP packets (no
data). Either way, they're still trailers, not headers. 

As I said, you can coin new words for these, but it's just misleading.
What you call a "header" is really what we already have as LITE, and
it's not a header. 

> All implementations have been tuned for
> them, and it would be naive to think that introducing protocol
> trailers in data path protocols won't cause issues with established
> deployment (some have already been highlighted).

LITE (or your "header") isn't compatible with established deployment. It
will show up as zero-length packets; it won't just "not show up". 

The real question here is how to interact with legacy receivers - Sec 8
already addresses that based on WG feedback. If we want to change that
algorithm, fine - but there are consequences. 

In the current approach: 

- IF receiver behavior is unknown, then the only safe thing to do is use
only truly optional options - ones that can be silently ignored. 

- If that's NOT the case, the ONLY TRULY SAFE behavior is to negotiate
use of those options that are NOT optional. It simply is NOT KNOWN TO BE
EQUIVALENTLY SAFE to simply send the options as part of LITE per se. 

LITE has its uses, but it is not a substitute for NOT SENDING A PACKET. 

Note that udp-opts already includes that advice. 

Joe