Subject: [tsvwg] Comments on recent UDP options work

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Nov 2018 08:03:05 -0800

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 08:16:38 -0800

One question (and clarification):

> On Nov 25, 2018, at 8:03 AM, C. M. Heard <[email-masked]> wrote:
> 
> 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.”
I didn’t understand that either. No variant of UDP options adds anything to the *UDP* payload; they all use space in the *IP* payload that extends beyond that of the UDP payload. That includes LITE.
> 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.
It my be possible that FRAG is not useful without LITE, but remember that LITE may be useful without FRAG.

As to determining which options are understood, we currently infer that from the options received (i.e., if you send an option, you indicate you can receive it too). The receipt of ANY of the core options implies support for all of them.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 25 Nov 2018 16:28:29 +0000

On 25/11/2018, 16:16, Joe Touch wrote:
>> On Nov 25, 2018, at 8:03 AM, C. M. Heard <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>  1. 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.”
>>
> I didn’t understand that either.
Where is the data portion of the fragment carried?
> No variant of UDP options adds anything to the *UDP* payload; they all 
> use space in the *IP* payload that extends beyond that of the UDP 
> payload. That includes LITE.
If it is always OK to return a UDP Options packet that has had the 
options area stripped (without the receiver knowing) - then I think the 
operation is correct. If that could result in an incomplete or incorrect 
datagram payload then I think the deisgn may be wrong.
>>
>>  1. 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.
>>
I think the point I saw was that LITE is complicated to implement, and 
also it is quite unlikely to work on many paths, because it is not 
possible to have LITE semantics and a CCO.
> As to determining which options are understood, we currently infer 
> that from the options received (i.e., if you send an option, you 
> indicate you can receive it too). The receipt of ANY of the core 
> options implies support for all of them.
I really do not think this should include FRAG. Support for fragments at 
the IP-layer is very much in doubt in other WGs, and the requirement 
that an endpoint "must" support FRAG, if a sender uses any options does 
seem worrying.
> Joe
Gorry

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 08:36:48 -0800

> On Nov 25, 2018, at 8:28 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
>>> On Nov 25, 2018, at 8:03 AM, C. M. Heard <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

It depends on whether it’s FRAG+LITE or FRAG only; the former puts it in the option area, the latter leaves it in the UDP payload.

>> No variant of UDP options adds anything to the *UDP* payload; they all use space in the *IP* payload that extends beyond that of the UDP payload. That includes LITE.
> If it is always OK to return a UDP Options packet that has had the options area stripped (without the receiver knowing) - then I think the operation is correct.

I don’t think that’s “OK” - i.e., that should NEVER be a legitimate function of any intermediate device. However, being robust to that behavior might be a consideration...

> If that could result in an incomplete or incorrect datagram payload then I think the deisgn may be wrong.

The design is not intended to overcome the arbitrary behavior of all intermediate devices. Again, “more robust” doesn’t mean “right”….

> I think the point I saw was that LITE is complicated to implement, and also it is quite unlikely to work on many paths, because it is not possible to have LITE semantics and a CCO.

We can leave that to the user, with the appropriate caveats.

> I really do not think this should include FRAG. Support for fragments at the IP-layer is very much in doubt in other WGs, and the requirement that an endpoint "must" support FRAG, if a sender uses any options does seem worrying.

FRAG is part of the core of UDP options; if an endpoint supports any of that core, it can be assumed to support the entire core. 

Support for fragments at the IP layer does interfere with the profit and effort model of vendors and operators but what we’re seeing “in other WGs” are the shopping around of ideas until they find a home. Let’s not confuse that with a groundswell.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Nov 2018 09:21:01 -0800

On Sun, Nov 25, 2018 at 8:28 AM Gorry Fairhurst wrote:
> > On Nov 25, 2018, at 8:03 AM, C. M. Heard wrote:
> > >  4. In the thread on "UDP Options Implementation Update," Tom Jones
> > >      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.
> > >

That was certainly what I inferred from the meeting materials and what I
intended to say in my comments.

> that an endpoint "must" support FRAG, if a sender uses any options does

I agree with Gorry on this point. I will be disappointed if in the end
the spec does not include FRAG, but I do not believe that it should be a
core option, given that a requirement to perform reassembly changes an
otherwise stateless protocol into a stateful one. In other words, it
should be allowed to support other UDP options without supporting
FRAG. In the current version of the spec, a sender can indicate support
for FRAG  by sending a UDP datagram (possibly empty) as a single
fragment (with or without LITE). In the absence of this signal or explicit
out-of-band pre-arrangement, UDP fragments should not be sent.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Sun, 25 Nov 2018 09:26:42 -0800

> The design is not intended to overcome the arbitrary behavior of all intermediate devices. Again, “more robust” doesn’t mean “right”….

But, the protocol does need to be correct. In the case of LITE, the
draft allows that receivers may interpret the same packet from a
sender in two very different ways. One receiver may see a UDP packet
with non-zero payload, but the other way is for an application to
receive a zero length UDP message. I don't know if this can be
considered correct. It's implicit in the the draft that receiving a
well formed zero length UDP message is innocuous to applications, but
I don't believe this has been proven. There should be more discussion
and supporting evidence for this.

Tom

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Nov 2018 09:37:51 -0800

On Sun, Nov 25, 2018 at 8:36 AM Joe Touch <wrote:
> On Nov 25, 2018, at 8:28 AM, Gorry Fairhurst wrote:
> > options area stripped (without the receiver knowing) - then I think
> > the operation is correct.
>
> I don’t think that’s “OK” - i.e., that should NEVER be a legitimate
> function of any intermediate device. However, being robust to that
> behavior might be a consideration...

I don't think Gorry was referring to an intermediate device stripping
the options area; I think he was referring to the behavior of a (correctly
implemented) legacy host, which ignores the IP payload data following that
indicated by UDP length and strips it off before passing the UDP datagram
to the application.

> The design is not intended to overcome the arbitrary behavior of all
> intermediate devices. Again, “more robust” doesn’t mean “right”….

The reason for hiding FRAG behind LITE is to protect a correctly
implemented legacy receiver from passing unassembled fragments
to the application layer.

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 09:38:16 -0800

All of these are soft state.

FRAG allows reassembly instead of drop, which is still consistent.

Frankly, if we’re not supporting FRAG - which is critical both to DNS and other transport uses and provides a core-protocol way around IP frag, then what’s the point of the rest of the options?

Furthermore, FRAG is endpoint state - that is ALREADY required at the IP layer. We’re basically moving where in the endpoint stack that function is likely to be used…

Joe

> On Nov 25, 2018, at 9:21 AM, C. M. Heard <[email-masked]> wrote:
>

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Nov 2018 09:41:47 -0800

On Sun, Nov 25, 2018 at 9:26 AM Tom Herbert wrote:
> sender in two very different ways.

Do you mean LITE, or FRAG? That is definitely true of FRAG
without LITE (and IMHO a good reason not to use FRAG
without LITE).

> One receiver may see a UDP packet
> receive a zero length UDP message.

Hello?

> It's implicit in the the draft that receiving a

I agree with this point.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Sun, 25 Nov 2018 09:50:44 -0800

> > sender in two very different ways.
Yes. Although, this characteristic would apply to any option that
change would fundamentally change how the packet is interpreted. If
the whole options can can be dropped and packet is still processed,
then there's really no such thing as "madatory to process" options.

> without LITE (and IMHO a good reason not to use FRAG
LITE+FRAG is the obvious case that leads to ambiguity on how a
reciever processes a packet.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Nov 2018 10:11:26 -0800

> reciever processes a packet.

OK, you are fixated on the empty datagram case. A legacy receiver sees
a sequence of empty datagrams; a receiver that implements LITE+FRAG
will see a single reassembled datagram. Agreed that it's an open
question whether the sequence of empty datagrams is harmless. If
it is not, it is necessary to ensure that LITE+FRAG is not sent without
prior negotiation or out-of-band arrangement. Oh, wait, the spec already
says to do that.

FRAG without LITE can of course create an ambiguity that is
demonstrably harmful. A legacy receiver sees a sequence of
non-empty datagrams that are acually fragments. Easy to come
up with scenarios where those apparent datagrams will be
misinterpreted. So be sure to pick on that case too; indeed,
emphasize it; but again, if the spec is followed, naked fragments
won't be sent to an unsuspecting receiver, either.

--cmh

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 25 Nov 2018 18:34:00 +0000

On 25/11/2018, 16:36, Joe Touch wrote:
>
>> On Nov 25, 2018, at 8:28 AM, Gorry Fairhurst<[email-masked]>  wrote:
>>
>>>> On Nov 25, 2018, at 8:03 AM, C. M. Heard<[email-masked]<mailto:[email-masked]>>  wrote:
>>>>
The latter would really concern me.
>> If that could result in an incomplete or incorrect datagram payload then I think the design may be wrong.
Who would implement something that currently does not work on many paths?
> We can leave that to the user, with the appropriate caveats.
We could - but there again I do not understand yet why it would be 
helpful to require conformant stacks to implement something that mostly 
isn't deployable at the moment.
> FRAG is part of the core of UDP options; if an endpoint supports any of that core, it can be assumed to support the entire core.
Personally, I disagree with this position.
> Support for fragments at the IP layer does interfere with the profit and effort model of vendors and operators but what we’re seeing “in other WGs” are the shopping around of ideas until they find…
There are memory and processing implications of needing to hold onto 
fragments waiting for reassembly and what to do with rogue packets 
containing fragments that you don't know whether they should be 
reassembled.

My comment conerned doubts that this functionality should be provided by 
UDP-Optiona and a suggestion it may be better provided by an application 
(perhaps e.g. a tunnel protocol endpoint?). I don't see how adding this 
as a UDP-Option function helps eliminate complexity or to manage 
fragments better.
Gorry

---

From: Tom Herbert <[email-masked]>
Date: Sun, 25 Nov 2018 10:42:29 -0800

> prior negotiation or out-of-band arrangement. Oh, wait, the spec already
The draft states:

"the LITE UDP option can safely provide that service only between
endpoints that negotiate that capability in advance".

That is not a normative requirement. Maybe this should read "Use of
UDP LITE option MUST be negotiated between endpoints before use". But
if negotiation is required and authoritative, then there should be no
legacy receivers of such negotiated options. However, a mechanism for
negotiation of UDP options has yet to be defined, it will be
interesting to see if that can be done in a robust way without bring
state into UDP.

Tom

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 11:50:04 -0800

UDP options do bring soft state into UDP, for at least some types of options.

See Section 10.

Joe

> On Nov 25, 2018, at 10:42 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 11:58:22 -0800

> On Nov 25, 2018, at 10:34 AM, Gorry Fairhurst <[email-masked]> wrote:
> 

The latter should not occur unless the receiver confirms anyway.

> Who would implement something that currently does not work on many paths?

So no IPv6, got it.

> We could - but there again I do not understand yet why it would be helpful to require conformant stacks to implement something that mostly isn't deployable at the moment.

But the same was true for the original UDP Lite too. We deploy things to change the Internet.

> Personally, I disagree with this position.

It’s there for a reason - the primary motivating case for the options in the first place. 

> There are memory and processing implications of needing to hold onto fragments waiting for reassembly and what to do with rogue packets containing fragments that you don't know whether they should be reassembled.

Yes, and there are memory and processing implications of processing UDP at all, so let’s ditch that. And TCP. And SCTP.

> 
> My comment conerned doubts that this functionality should be provided by UDP-Optiona and a suggestion it may be better provided by an application (perhaps e.g. a tunnel protocol endpoint?). I don't see how adding this as a UDP-Option function helps eliminate complexity or to manage fragments better.

Everything CAN be implemented st the app layer; your argument basically deprecates all transport protocols. I disagree with that. UDP needs these options - esp. fragmentation support - exactly because we don’t want to reinvent it repeatedly at the app layer and it’s useful to provide it at the transport.

Anyone who doesn’t WANT to use it is free to not turn it on, of course.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Nov 2018 12:33:57 -0800

On Sun, Nov 25, 2018 at 10:34 AM Gorry Fairhurst wrote:
> My comment concerned doubts that this functionality should be provided by
> UDP-Options and a suggestion it may be better provided by an application

The attraction that I see for FRAG as a UDP-Option is that it offers incremental
deployability in the important case of DNS (and probably in some other cases
as well). Its use can be negotiated on a transaction-by-transaction basis. The
negotiation signal from a client that supports it (use of a null FRAG option in
a request) will be ignored by a legacy server. And an upgraded server will not
use the option unless the client negotiates it. So, upgraded client can talk to
a legacy server, and a legacy client can talk to an upgraded server, without the
need to introduce any extra protocol exchanges.

Can the same be said for a tunnel endpoint protocol?

Mike Heard