search

tsvwg / draft-ietf-tsvwg-udp-options

0 stars 0 forks source link

GF/CMH/ZS: WGLC Comments - Use cases #42

Open gorryfair opened 2 months ago

gorryfair commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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.