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

["C. M. Heard" <[e-mail]>]

On Mon, Jul 15, 2019 at 11:47 PM Joe Touch wrote:
> Did you had read my earlier post today about using OCS only on transmit
> for LITE - as a user choice?
>
> That costs on transmit *but not receive* and allows errors in the LITE
> data *if* the packet doesn’t cross a buggy middlebox afterwards (which
> kills the packet no matter what we do anyway).
>
> And in that context, can you update your response below?
[...]
> > I'm of two minds about LITE: I don't see a way to make it work with the
> > protocol header format or something similar, but I don't see a way to
> > make it safe with the trailer format of draft-ietf-tsvwg-udp-options-07.
> > I could accept seeing it remain with a "for mutually consenting parties
> > only" health warning, but unless it solves actual problems that
> > UDP-Lite does not, maybe it's best to say "just use UDP-Lite." It does
> > seem as if the fond hopes of easy traversal of middleboxes that block
> > protocol 136 are not to be, as LITE defeats checksum compensation.

There are actually a couple of live proposals on the table. The trailer
version of LITE that has OCS on transmit only (with OCS covering the LITE
data) has the disadvantage that the protocol control information --
specifically the IP payload length (for IPv6) and the length of the LITE
data in the option (for IPv4 and IPv6) -- is not protected. I think that
these problems can be elegantly solved by by Derek Fawcus's idea to change
the option length field to be a checksum coverage field in the version of
the protocol header format that I proposed, and I'm going to reply to his
message (and your comments) to help flesh out the details.

Note that there is a significant limitation to **any** proposal that has
a compensated checksum on transmit with partial checksum coverage on
receive: packets with errors in the insensitive part will not traverse
meddling middleboxes that actually **need** the compensation. Even with
that limitation, though, it should provide better service to applications
that would want to use it than does conventional UDP, while at the same
time providing better middlebox traversal properties than UDP-Lite.

So, yes, let's continue to explore this idea.

Mike