[tsvwg] Comments on recent UDP options work

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

After reviewing the IETF 103 meeting minutes and presentations and the
recent thread on "UDP Options Implementation Update" I have a few comments.

   1. First thanks to Tom Jones and collaborators for the pilot
   implementation and tests, In a way, the results are more interesting than
   reassuring, give that even with the checksum compensation option (CCO, see
   https://tools.ietf.org/html/draft-fairhurst-udp-options-cco-00) drop
   rates were in the 5% - 28% range.
   2. I would support adopting CCO as an alternative to OCS and making its
   use RECOMMENDED. Although CCO is a bit more expensive than OCS, the
   advantage i(for deployability) of having drop rates go from an average of
   greater than 50% to around 20% trumps the extra complexity. If we wish to
   retain LITE for for its originally intended purpose -- i.e., to allow for
   only partial checksum coverage -- I think we would also want to keep OCS as
   an alternative for this use case; using CCO with LITE would defeat that
   purpose. Of course, the high drop rates observed without CCO put into
   question the practical viability of the latter combination.
   3. The discussion of the use cases for the FRAG option as described in
   the minutes focused on tunnels. This overlooks DNS, which appears to me to
   be a potentially more important use case. A client could include a FRAG
   option indicating a complete datagram in a request as a signal that it
   supports the FRAG option; the server would then have the option to use UDP
   fragmentation to send a reply that would otherwise need IP fragmentation.
   Given the observed drop rates for UDP options with DNS over UDP this would
   definitely not be a panacea, but it might be one of a number of useful
   tools to combat the high drop rate of IPv6 fragments.
   4. In the thread on "UDP Options Implementation Update," Tom Jones said "The
   current spec puts data in the UDP payload, which does not seem correct." If
   I understand this comment correctly, I think the issue is addressed by
   using it in combination with LITE. If in the end we don't retain LITE, it
   would still be possible to re-specify the FRAG option to get the same
   effect (i.e., make all data in the fragment part of the option); in this
   case, we would need a separate option to signal that FRAG is understood, in
   order to support (3) above.
   5. In connection with (4) above I have a question for Tom and his
   colleagues: did any of your test cases include packets with options but no
   UDP user data (i.e., with UDP Length == 0)? If this particular case fails
   dramatically, even with CCS, it would IMHO be a nail in the coffin of
   FRAG+LITE (or the variant FRAG discussed above). On the other hand, if it
   works, it would confirm the viability of FRAG+LITE (or the variant FRAG)
   without having to do a full implementation.

Thanks and regards,

Mike Heard