Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

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

On Thu, Apr 11, 2024 at 4:20 AM Zaheduzzaman Sarker <
[e-mail]> wrote:

> On Tue, Apr 9, 2024 at 8:26 PM C. M. Heard <[e-mail]> wrote:
>
>> On Tue, Apr 9, 2024 at 6:09 AM Zaheduzzaman Sarker <
>> [e-mail]> wrote:
>>
>>> On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <[e-mail]>
>>> wrote:
>>>
>> [ ... ]
>>
>>> So.   I think given this, it is OK for the endpoints to send information
>>>> in UDP options which can be read (only) by the transit nodes and they can
>>>> indeed react to this. That has always been possible with tunnels, extension
>>>> headers, and transports - at least those not using transport encryption.
>>>> This comes with positive and negative impacts.
>>>>
>>>> In today’s world, a designer can choose to protect all of the transport
>>>> eg using QUIC - and many designs will follow that path. Although, there is
>>>> a large body of work in the IETF that still directly uses UDP. That to me
>>>> is OK if that best fits the use.
>>>>
>>>
>>> Yes, UDP should be considered as transport protocol. It would be good to
>>> have a view on how many of those large body of work uses or envision to use
>>> UDP options in clear. This would boost the motivation for this work and
>>> back up the need of UDP options.
>>>
>>
>> It was recognized early in the development of the UDP options that they
>> would be useful for DPLPMTUD. This use case is documented
>> in draft-ietf-tsvwg-udp-options-dplpmtud, which has actually been ready for
>> publication for quite some time.
>>
>> Another potentially attractive use case was use of UDP options to allow
>> UDP-based request/response protocols such as DNS to send large responses
>> without relying on IP fragmentation (especially IPv6 fragmentation). Here's
>> how this would work: client includes the MRDS option in the request;
>> responder ignores said option unless it is option aware and has UDP options
>> enabled, in which case it can use the option to determine how to send a
>> large response using UDP fragmentation. This is incrementally deployable as
>> long as legacy applications ignore the UDP surplus area. We don't have an
>> I-D describing this use case. but one could be written if it would help to
>> back up the need for UDP options.
>>
>
> I agree it would useful to record this usecase.
>

The promised draft has now been posted; see
https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses
.

On Tue, Apr 9, 2024 at 12:17 PM Christian Huitema <[e-mail]>
wrote:

> Did you check that assumption with DNSOP? I don't see the DNS users
> clamoring for such a solution. Indeed, most DNS development seems to be
> focused on avoiding UDP fragmentation by either picking a small packet
> size, or using transports like TCP, DoT, DoH or DoQ that do include their
> own fragmentation mechanisms.
>

The idea of using UDP fragmentation for large DNS messages has not, to the
best of my knowledge, been checked with DNSOP up to now. So I posted the
draft notification to the DNSOP list and requested comments from the
subject matter experts over there.

Thanks and regards,

Mike Heard

>