Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[Paul Vixie <[e-mail]>]

On Sun, Jun 13, 2021 at 03:00:35PM -0700, C. M. Heard wrote:
> Responding to just this one specific point ...

same.

> On Sun, Jun 13, 2021 at 12:55 PM Joseph Touch wrote:
> 
> > And no, I do not think we should rely on RMSS to indicate that this is
> > available. Note that a receiver would have to indicate RMSS and know the
> > path MTU to know how many fragments it would actually take; we don???t
> > require path MTU discovery for UDP options, so that???s an undue burden.
> > Besides again injecting state into UDP.
> 
> For IPv6 -- where fragmentation has the greatest issues -- we are
> guaranteed a minimum MTU of 1280 bytes. A DNS server operating over IPv6
> would be able to serve up a fragmented response with the right number of
> 1280 byte fragments (or else set the TC bit) if it received the MRSS option
> in the request from the client.

computing UDP payload size by subtraction requires either that one be inside
the network stack (sometimes this means "in the kernel") so as to know the
interface MTU and perhaps the path MTU, as well as the IP6 header and option
sizes. when this information is unavailable, for example when running inside
a DNS responder, pessimistic assumptions have to be made, such as a payload
maximum for DNS data of 1232 or even 1220 octets. this is not just pessimistic
but also pessimal, and ought to be avoided.

i have high hopes for a non-pessimal future to be reached via:

https://www.rfc-editor.org/rfc/rfc8899.html

for which assumptions such as 1280, 1232, or 1220 will be "of last resort".
i think this may mean i disagree with joe's estimation of "undue" above. when
commodity (end user) hardware reaches terabit speed, we are going to wish we
were not shackled to the MTU of 10-megabit ethernet for wide area packets. in
fact i already wish this, but in the future the wish will be universal. it was
not too early to plan and develop for this future starting ~20 years ago, and
it is definitely not too early today.

-- 
Paul Vixie