Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt

[Joe Touch <[e-mail]>]

Hi, Mike,


On 2/28/2017 10:58 AM, C. M. Heard wrote:
> Greetings,
>
> I am very pleased with the latest version of this draft, and in particular
> with the proposed Fragmentation option. It cleanly solves the problem of
> providing an optional fragmentation capability in UDP that can be
> incrementally deployed. It appears to be a viable way to solve the problem
> of fragmented DNSSEC responses getting dropped because of middleboxes
> filtering IPv4 or IPv6 fragments.

That's a very good point - I'll add that to the discussion of the option.

>  Application layer solutions have been
> proposed (see https://tools.ietf.org/html/draft-muks-dns-message-fragments),
> but the current proposal has the advantage that it will work for any
> UDP-based protocol. It will work especially well for request-response
> protocols such as DNS where the requests typically are small (not requiring
> fragmentation) but the responses may be large. To use it, the client sends
> the request in an unfragmented UDP datagram but appends a Fragmentation
> option with Offset and M both zero. If the server does not support UDP
> options, it ignores the trailing option and behaves as it does today. If
> the server does support UDP options and the response won't fit in a single
> UDP datagram without causing IP layer fragmentation, it transmits the
> response in several datagrams, using the UDP fragmentation options. This
> will work especially well for IPv6, where the path MTU is guaranteed to be
> at least 1280 bytes.
>
> Back in 2013 several proposals for UDP layer fragmentation surfaced during
> a discussion on the 6man list about whether to deprecate IPv6 fragmentation
> (one was in https://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html).
> None of those proposals solved the problem of incremental deployability,
> however, as this one does. Thanks and congratulations for coming up with
> an elegant solution.
I have to give credit to Mike Smith for suggesting it.

> I do have some technical comments to make on the Fragmentation option.
>
> First, I would like to suggest that the post-reassembly user data length
> and optionally a post-reassembly user data checksum appear in the UDP
> Fragmentation option. The reason for including a post-reassembly length is
> to provide a hint to the implementation how much buffer space to reserve;
> in order to be foolproof in the face of packet reordering, this needs to be
> in every fragment. The optional post-reassembly checksum would need to be
> in at least one Fragmentation option and (like the post-reassembly length)
> would have to have be the same if it appeared more than once. Its main
> value is that it provides a stronger verification that the reassembly
> process was done correctly than the fragment-by-fragment checksum in
> the UDP header.
I'm thinking now about the ordering of options. I'd really like to allow
FRAG to precede others, especially LITE. I see your point about the
checksums of the pieces vs. the whole...

>  Finally, if used in conjunction with the Lite option, it
> provides a means to overcome the following issue:
>
>    The Fragmentation option needs to be used with extreme care because
>    it will present incorrect datagram boundaries to a legacy receiver.
>
> If the Fragmentation option includes its own post-reassembly checksum,
> then a Lite option could be inserted immediately following the UDP
> header in each fragment, without loss of functionality. Implementations
> that do not support UDP options would see UDP fragments so constructed
> as empty UDP datagrams and would discard them, removing the danger of
> accidental misinterpretation.
Is see how that's useful, but it would also appear to mean we might be
able to use LITE twice - once as this trick to hide fragments (which is
elegant - thanks!), but also to allow the use of LITE in the final
result. I'm not sure whether that makes sense yet, though - if you check
to see that the whole thing is there, there's little point in allowing
part of the packet to not be checksummed (it already would be).

So maybe LITE couples with FRAG only in the way you mention, and no other?

> I also have an editorial comment on this option. Figure 15 shows the option
> length as 12 bytes and the Identification field length as 8 bytes, while the
> text says that the Identification field is 32 bits (4 bytes). This figure
> needs to be updated to match the text (whatever that turns out to be) and
> it also needs a new caption.
Yeah - sorry. That was sloppy of me. I did (FWIW) try to push all the
pending updates into the text in about half a day yesterday, so I
apologize for it being draftier than it should be. Thanks for pointing
that out.

> Finally, the text is silent on how Alternate Checksum (ACS) interacts with
> the Lite option and with the Fragmentation option. My assumption would be
> that ACS covers the entire payload in one datagram, irrespective of the
> presence or absence of Lite and Fragmentation, but it would be good to
> make this explicit.

Absolutely - as I noted, I need to think a little more about this issue
and make a recommendation. Glad to hear what others think.

AFAICT:
    OCS covers the header in each fragment
    ACS, being an alternative to the UDP checksum, covers the UDP user
data in each fragment (same as the UDP checksum, so not LITE)

As was noted, we might need a total "reassembled" checksum.

I'm not clear on whether it makes sense to use LITE with FRAG (except as
the trick noted before, to hide fragments from legacy receivers).

Joe