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

[Joe Touch <[e-mail]>]

Notes embedded below...

So far, I'm beginning to see that this argument boils down to 1 byte. If
that's all it is, then fine - let's add OCS as a fixed field at the
head, possibly after NOPs. 

NOTE: OCS would still probably need to have a way to be disabled, ala
UDPv4 checksums, by setting to zero. 

So no matter what you do, they're still easily optional unless we decide
to FORCE the user to do otherwise. Why exactly would that be the case?

Joe 

On 2019-07-11 13:01, Black, David wrote:

> Commenting as an individual, **not** as a WG chair.
> 
> -- Option Checksum (OCS)
> 
> The IETF 104 tsvwg minutes match my impression that the topic of whether the offsetting option checksum (OCS) should be optional vs. mandatory remains an open issue for UDP options.

Tom has kept this issue open for over a year; there hasn't exactly been
a groundswell behind the issue. I also note that you seem to argue
yourself out of your own support below, FWIW. 

> For my part, I've seen strong "running code" evidence of what breaks when the OCS is omitted,

In SOME Internet paths. The issue is whether we need to require this
even when we might not need it in the future. 

But note that the same thing is largely true for UDP checksums - they
find real errors, yet some people choose to turn them off (esp. for
IPv4). So even if we kept OCS as a required field, we would still need a
way to turn them off in a corresponding way (e.g., set to zero). 

> in contrast to almost no evidence of things broken by the presence of OCS (computed to offset the UDP checksum calculation when that is done over IP length instead of UDP length).

I think you contradict this below, here: 

> ...
> One exception to OCS being mandatory that makes sense to me is that OCS doesn't seem to make a lot of sense with LITE, as the OCS would cover all the LITE payload data, thereby defeating the LITE goal of not having to checksum data whose reliability is not of interest.   One consequence is that UDP Options become unreliable when LITE is used, which may have implications for which UDP options are acceptable to use with LITE.  An important tradeoff is that LITE won't work on network paths that pass  UDP Options only when OCS is present.

There are some other possibilities, such as including an OCS on transmit
but not checking it on each fragment received. That would trick
middleboxes as needed but avoid duplicate work at the receiver (which is
where load tends to be bigger anyway). 

This is both why the current doc indicates OCS as both optional and
default enabled. In the future, if/when it isn't needed, we can remove
it that way - as well as disabling it if needed/possible for LITE. 

> -- Other uses of surplus space
> 
> Any hypothetical existing use of surplus space is incompatible with both UDP options and a new surplus header.  While I haven't seen evidence of any such existing use "running code," making the OCS mandatory helps defend against that possibility, as well as against bad endpoint implementations that put whatever junk bytes happen to be lying around in memory into that extra space, improving UDP Options robustness.

*Using* OCS accomplishes this - and remember, it's default to being
used. 

Making OCS mandatory is a decision - why do you think that's critical
for us to make for all future users? 

And regarding the last point, if you really care, users are always
welcome to just leave OCS on as defaulted anyway. 

--