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

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

On Fri, Sep 3, 2021 at 3:09 AM Tom Jones <[e-mail]> wrote:
> On Thu, Sep 02, 2021 at 08:07:38 PM -0700, C. M. Heard wrote:
> >
> > 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.
> >
>
> Talking with Gorry, we think we will remove this text from the next
> revision of the draft.

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