Re: [tsvwg] UDP REQ/RES Options - per segment or per datagram

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

On Wed, Jul 7, 2021 at 9:44 PM Joseph Touch wrote:

> Hi, Mike,
>
> I’ll try to take this in one shot, but it might be useful to followup in
> separate threads.
>

I am following up in separate threads as suggested. This one is for the
REQ/REs options.

On 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 want to hear what the authors of
draft-fairhurst-tsvwg-udp-options-dplpmtud have to say about this, but I
don't see a use case for sending dplpmtud probe packets that use UDP
fragmentation. Indeed, that seems to be a completely useless and
unnecessary complication.



> 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 fragment of a datagram
> that needs to be fragmented; this causes duplicate REQ tokens. Gorry, any
> thoughts? (*)
>
>
> I don’t see UDP as replicating options without direction from the
> application layer. This isn’t like IP where there was never intended to be
> such control. For UDP, we should assume that options are included per
> fragment or per datagram *at the discretion of the upper layer*.
>

What is the reason and benefit of providing that level of control and
responsibility? How will the application use the information on responses
to UD{ fragments?

I am reminded of the words of one of my mentors, who described such an
excess of flexibility as "independently steerable front wheels".

We do not need that. We need this spec to be as simple as possible and
unambiguous to implement. Making UDP fragments visible to the protocol
running on top of UDP without a clear reason to do so is a clear violation
of those principles.

Mike Heard