GF/CMH/ZS: WGLC Comments - Use cases

[gorryfair]

On Tue, Apr 9, 2024 at 8:26 PM C. M. Heard [heard@pobox.com](mailto:heard@pobox.com) wrote:

On Tue, Apr 9, 2024 at 6:09 AM Zaheduzzaman Sarker <[zahed.sarker.ietf@gmail.com](mailto:zahed.sarker.ietf@gmail.com)> wrote:

    On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <[gorry@erg.abdn.ac.uk](mailto:gorry@erg.abdn.ac.uk)> 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.

(Added by GF from TSVWG list)

[Mike-Heard]

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.

That draft has now been posted; see https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses. Comments have been requested from DNSOP.

See also Issue #30.

[Mike-Heard]

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). [ ... ] 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.

That draft has now been posted; see https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses. Comments have been requested from DNSOP.

See also Issue #30.

DNSOP interest has not been overwhelming, to say the least. To date there has been only one comment, and it was not favorable. See https://mailarchive.ietf.org/arch/msg/dnsop/EhUq8tZF8Qm-iZk4eUAnjsCGXUg/ and subsequent messages in the thread. Additionally, as noted in the Discussion section of the draft, it is not a slam-dunk that UDP fragmentation would save significant resources compared to fallback to TCP. Based on that, it's not clear that it is appropriate to highlight this use case.

[Mike-Heard]

Recent discussion on the v6ops and tsvwg lists suggests that there is still interest in this use case, just not from DNSOP (see the thread starting with https://mailarchive.ietf.org/arch/msg/tsvwg/YG7jeLoD8nLrgzpdhZxbegR8sfY/). One point of view is that whether the DNS community thinks this isn’t needed or not is less the issue than that it COULD be useful to them.

[gorryfair]

One resolution is to note this potential use-case in the draft.

[jtouch]

I think we could cite the pending I-D on use cases. Whether the UDP community thinks this isn’t needed or not is less the issue that it COULD be useful to them. I think they’re being short-sighted in assuming only current solutions - especially given their most recent document should have at least addressed UDP options.

[Mike-Heard]

Requested text added in -33 Section 5.

[Mike-Heard]

Specifically, the text shown below in bold was added to the last paragraph of Section 5:

UDP was originally intended to assume such capabilities could be provided by the user or by a layer above UDP. However, enough protocols have evolved to use UDP directly, so such an intermediate layer would be difficult to deploy for legacy applications. UDP options leverage the opportunity presented by the surplus area to enable these extensions within the UDP transport layer itself. Among the use cases where this approach could be of benefit are request-response protocols such as DNS over UDP [He24].

Note: [He24] is an informative reference to draft-heard-dnsop-udp-opt-large-dns-responses

Kindly let me know whether the proposed resolution is satisfactory or still needs work.

[jtouch]

That seems sufficient to me.