Subject: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-07

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 12:56:09 -0700

>From the draft:

"Legacy receivers interpret these as zero-length payload packets
(i.e., UDP Length field is 8, the length of just the UDP header),
which would not affect the receiver unless the presence of the packet
itself were a signal."

This is an improvement over previous drafts in that the problem is at
least acknowledged, but it provides no guidance on resolving the
issue. The protocol as described may break legacy applications. It
seems like there should be a lot more words around this. If the
problem can't be eliminated in the protocol, then at least it should
be mentioned in usage guidelines.

>From the draft:

"The primary purpose of OCS is to detect non-standard (i.e.,
non-option) uses of the options area".

Given that the checksum is optional, I don't see how this works to
detect non-standard use of the checksum area. For instance, if some
random garbage bytes are in the option area then the only way the
non-standard use is detected is if by chance the type for OCS happens
to appear in the data and is parsed as being an OCS option. Of course
that's exceedingly unlikely to happen, so garbage data is likely to be
proessed as options.

As I mentioned previously, UDP options space should start with a fixed
size header that includes a two byte checksum. This will eliminate any
ambiguity and solves other problems (like the corrupted OCS type field
problem),

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Mar 2019 18:49:09 -0700

> that's exceedingly unlikely to happen, so garbage data is likely to be

A receiver that cares can require OCS, as has already been noted several times (I can check in the next rev that this is mentioned in the text).

> ambiguity and solves other problems (like the corrupted OCS type field

That just forces senders to use OCS, which wastes space when it’s not needed or desired (or the space is needed for other purposes). It also forces a particular alignment that may not be desired.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 19:24:08 -0700

> A receiver that cares can require OCS, as has already been noted several times (I can check in the next rev that this is mentioned in the text).
Considering that this is an application based mechanism, how would the
average user even know to care about this? It's better to not give the
option and just provide something that is robust out of the box.

> That just forces senders to use OCS, which wastes space when it’s not needed or desired (or the space is needed for other purposes). It also forces a particular alignment that may not be desired.
The overhead of header with checksum, length, and type and alignment
to four bytes is at four to seven bytes (minus three if the OCS would
be enabled). IMO the overhead, both on the wire and processing, is
inconsequential to the benefits of robustness and extensibility in
using the surplus space that a header offers.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Mar 2019 19:54:10 -0700

> On Mar 11, 2019, at 7:24 PM, Tom Herbert <[email-masked]> wrote:
> 
> average user even know to care about this?

The same way they know and care about udp checksums or not.

> It's better to not give the

We already have plenty of choices that are more risky, including CS=0.

The point is to be flexible - were not designing for today only.

And space - even a few bytes - is absolutely a significant consideration.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 20:34:52 -0700

> We already have plenty of choices that are more risky, including CS=0.
That's more an argument that UDP checksums should not be zero, rather
than a fixed checksum is not needed in UDP surplus space. I agree with
that. Given that every NIC offloads the checksum anyway, the
recommendation really should be to always use the UDP checksum (it's
required in IPv6 anyway and we get better performance in cases of
encapsulation).

> The point is to be flexible - were not designing for today only.
Robustness trumps flexibility.

> And space - even a few bytes - is absolutely a significant consideration.
It depends on several factors whether the overhead is justified. For
instance, a four byte alignment requirement really does have any
impact since IP and UDP are already four byte aligned and MTUs are
almost always divisible by four (i.e. alignment doesn't reduce
available MTU). If the common deployment case is to always enable OCS
(seems like in Appendix A of the UDP options draft the intended
default is to enable it), then the overhead of the header reduces to
one byte. An overhead of one byte really is not worth discussion.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 00:38:04 -0400

> On Mar 11, 2019, at 11:34 PM, Tom Herbert <[email-masked]> wrote:
> 
> That's more an argument that UDP checksums should not be zero,

We tried to force that with IPv6 then realized it isn’t what we wanted. 

Same logic applies here for the same reason. 

Joe