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

[Joseph Touch <[e-mail]>]

Hi, Paul,

> On Jun 14, 2021, at 2:49 PM, Paul Vixie <[e-mail]> wrote:
> 
> 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.

Yes, that’s what is expected - per RFC 1122, Sec 4.1.4 GET_MAXSIZES().

> 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 a stack supporting UDP fragmentation, this would be the same as shutting off IP source fragmentation but allowing UDP fragmentation.

> 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.

Why is that not GET_MAXSIZES() as per RFC 4.1.3? That’s supposed to be a requirement. 

> if fragmentation
> is available then the size might be close to "64K" which is fine.

It would be limited by RMSS in UDP options (the UDP receiver max reassembly size).

> 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.

Agreed - that’s what the interface in RFC 1122 is supposed to provide, for exactly that reason.

Joe