Subject: Re: [tsvwg] Can DPLPMTUD for UDP Optionsbe considered to be adopted by tsvwg?

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Sep 2021 20:02:24 -0700

I certainly support adoption. There is one substantive issue that I have
noticed:

In Section 3.2.1 (page 4) the draft says:

   Implementations MAY track multiple requests and respond acknowledging
   them with a single packet.

That contradicts the following provision in draft-ietf-tsvwg-udp-options-13:

   >> Except for NOP, each option SHOULD NOT occur more than once in a
   single UDP datagram. If an option other than NOP occurs more than
   once, a receiver MUST interpret only the first instance of that
   option and MUST ignore all others.

This inconsistency must be resolved before this draft (or
draft-udp-options) can progress.

Thanks,

Mike Heard

On Mon, Aug 30, 2021 at 11:24 AM Gorry Fairhurst <[email-masked]>
wrote:

> We submitted revision -05 of draft-fairhurst-tsvwg-udp-options-dplpmtud
> a couple of weeks ago. This, like the last rev, was mainly to tidy NiTs.
> The protocol spec has not changed.
>
> The authors are now asking if this can be adopted to progress with UDP
> Options through to RFC publication.  We've asked for this to be added to
> the Agenda for the next Interim, and thoughts from the WG on-list or at
> that meeting will be most welcome!
>
> Best wishes,
>
> Tom & Gorry
>
> (as individual document authors).
>
>

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Sep 2021 20:07:38 -0700

[ resend with working address for Tom Jones ]

Thanks,

Mike Heard

---

From: Tom Jones <[email-masked]>
Date: Fri, 3 Sep 2021 11:13:49 +0100

> draft-udp-options) can progress.

Talking with Gorry, we think we will remove this text from the next
revision of the draft.

- Tom

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 3 Sep 2021 08:22:37 -0700

On Fri, Sep 3, 2021 at 3:09 AM Tom Jones <[email-masked]> wrote:
> On Thu, Sep 02, 2021 at 08:07:38 PM -0700, C. M. Heard wrote:
> >

Thank you, that seems to be the simplest resolution.

Another point that came up in previous discussions:

In the thread "UDP REQ/RES Options - per segment or per datagram" (see
https://mailarchive.ietf.org/arch/msg/tsvwg/_MICN4odgRlwc2qK2uJem92yt_E/
and preceding messages), Joe Touch and I sparred over whether DLPMTUD
probe packets would ever be subject to UDP fragmentation. Here is a
summary of the discussion:

On Fri Jul 30, 2021 at 5:21 PM Joseph Touch wrote:
> On Fri Jul 30, 2021 at 5:05 PM C. M. Heard wrote:
>> I am following up in separate threads as suggested. This one is for
>> the REQ/REs options.
>>
>> On Sat, Jun 26, 2021, at 4:53 PM, C. M. Heard wrote:
>>> The REQ and RES options exist for the benefit of DPLPMTUD and are
>>> intended to be sent on a PLPMTU Probe Packet, which itself must not
>>> be further fragmented (the probe packet will not serve its purpose
>>> if it is fragmented to make it get to its destination). Ideally,
>>> these options are used on packets with padding only and no user
>>> data; such packets would be generated and consumed entirely within
>>> the transport layer or a shim. As they are not subject to
>>> fragmentation, they can be considered complete datagrams.
>
> You assume these are not UDP fragmented; I do not. DPLPMTUD could be
> used to determine ways to avoid IP fragmentation but that doesn’t
> mean it prohibits the use of UDP fragmentation. All that is required
> is that the probes are not *IP* fragmented.

I would like to see a clear statement in the WG version of
draft-fairhurst-tsvwg-udp-options-dplpmtud on this point.

Also (speaking to the point of REQ/RES options that were the direct
concern of the thread), I stated:

>> In addition, it seems to me that there is little or no value in
>> taking a REQ option from the user and replicating it on every
>> [UDP] fragment of a datagram that needs to be fragmented; this
>> causes duplicate REQ tokens. Gorry, any thoughts? (*)

and it would be good to hear your comments on that, too.

Thanks and regards,

Mike Heard