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

[Paul Vixie <[e-mail]>]

On Sun, Jun 13, 2021 at 05:04:03PM -0700, Joseph Touch wrote:
> 
> > On Jun 13, 2021, at 3:56 PM, Paul Vixie <[e-mail]> wrote:
> > ...
> > 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.
> 
> That???s correct; that???s exactly how TCP MSS works. The UDP stack can make
> this information available to the user.

TCP MSS is different, because TCP segments are of elastic size, because
message boundaries are not retained between the TCP user and the network.

no UDP stack has ever made payload size (per interface, per destination)
information available in a portable way. at best we can learn the first-hop
MTU or perhaps the PMTU and then we begin subtracting, pessimistically.

the difference is, a UDP user currently knows that a message will be a packet,
and can ask to shut off source fragmentation to assure this. in the UDP
Options world, one UDP message from a user might become more than one
packet on the network. and that's fine, but it's not what i'm asking about.

> > when this information is unavailable, for example when running inside
> > a DNS responder,
> 
> A DNS responder would not be creating UDP option packets;
> it creates user that it passes to UDP. The same way TCP
> keeps ithis info on a per-socket basis, UDP is expected to.

we will need a portable kernel/user API that allows a UDP user such as DNS
to learn the maximum message size tolerated by that socket. if fragmentation
is available then the size might be close to "64K" which is fine. but the
payload budget left over after IP6 or IP4 headers and options, and after UDP
options, is something the UDP user should not try to guess, using subtraction,
with pessimism as to how much overhead each (invisible) layer will occupy.

-- 
Paul Vixie