[tsvwg] Re: Resolving UDP Options Issue #52

["C. M. Heard" <[e-mail]>]

Greetings,

After discussion between the author, the editor, and the document shepherd,
the editor's current thinking is to address Issue 52
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/52> with the
following text:

>> Endpoints supporting UDP options MUST be capable of fragmenting and
reassembling at least two fragments, *each of a size that will fit within
the standard Ethernet MTU of 1,500 bytes. This corresponds to a maximum
pre-fragmentation or post-reassembly UDP packet size (including the UDP
header and any per-datagram UDP options) of 2,926 bytes for IPv4 and 2,886
bytes for IPv6. Note that these maximum sizes are not guaranteed to be
achievable under all circumstances; for further details, please see Section
11.6.*


Based on the discussion in that issue, I have also opened Issue #63
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/63> to
enhance the MRDS option to include both the total size and number of
fragments that an endpoint can reassemble. That has resulted in a
significant proposed change to Section 11.6:

The Maximum Reassembled Datagram Size (MRDS, Kind=5) option is a 16-bit
indicator of the largest reassembled UDP datagram that can be received,
including the UDP header and any per-datagram UDP options, *accompanied by
an 8-bit indication of how many UDP fragments can be reassembled*. MRDS
size is the UDP equivalent of IP’s EMTU_R but the two are not related
[RFC1122]. Using the FRAG option (Section 11.4), UDP packets can be
transmitted as transport fragments, each in their own (presumably not
fragmented) IP datagram and be reassembled at the UDP layer. *MRDS segs is
the number of UDP fragments that can be reassembled.*

  +-------+-------+-------+-------+---------+
  | Kind=5| Len=5 |   MRDS size	  |MRDS segs|
  +-------+-------+-------+-------+---------+

  	Figure 14	UDP MRDS option format

>> Endpoints supporting UDP options MUST support a local MRDS size of at
least of *2,926 bytes for IPv4 and 2,886 bytes for IPv6. Support for larger
values is encouraged.*

*>> Endpoints supporting UDP options MUST support a local MRDS segs value
of at least 2. Support for larger values is encouraged*.

*These parameters plus the PMTU allow a sender to compute the size of the
largest pre-fragmentation UDP packet that a receiver will guarantee to
accept. Suppose that MMS_S is the PMTU less the size of the IP header and
the UDP header, i.e., the maximum UDP message size that can be successfully
sent in a single UDP datagram if there are no IP options or extension
headers and no UDP per-fragment options. Then size of the largest
pre-fragmentation UDP packet that the receiver will guarantee to accept is
the smaller of the MRDS size and*

*(MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8*

*where Total Per-Frag IP/UDP Options includes the size of all IP options
and extension headers and all per-fragment UDP options except for OCS and
FRAG that are in the sequence of UDP fragments.*

*>> If no MRDS option has been received, a sender must assume that MRDS
size is 2,926 bytes for IPv4 and 2,886 bytes for IPv6 and that MRDS segs is
2, i.e., the minimum values allowed.*

It would be helpful if the WG would comment on these proposals (either to
the list or, preferably, on github), ideally taking into account their
inter-relationship.
Thanks and regards.

Mike Heard

On Mon, Aug 5, 2024 at 2:58 PM C. M. Heard <[e-mail]> wrote:

> Greetings,
>
> By way of background:
>
> On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote:
>
>> (11.4) 2 fragments/3000 bytes as a minimum will work, of course, but it
>> seems like an odd number. This seems to be related to the canonical 1500B
>> MTU, but that would imply that 2 fragments would be 2926 for IPv4 and 2886
>> in IPv6, if my math is correct. (To be clear, I can live with 3000)
>>
>
> Note that Section 11.6 currently requires that endpoints MUST support a
> local MRDS size of at least 3,000 bytes.
>
> I opened Issue #52
> <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/52> on
> April 22, 2024 to address this comment, with a proposal to change the limit
> from 3,000 bytes to 2,926 bytes. While trying to craft suitable text,
> discussion with the author revealed the following problem: if an endpoint
> advertises either the proposed value (2,926 byes) or the current one (3,000
> bytes) in the MRDS option, then* more than two fragments* will be
> required to send a (pre-fragmentation or post-reassembly) packet of that
> size, even if the MTU is 1,500 bytes (which is likely maximum outside data
> centers). And none of the three values (2,886, 2,926, or 3,000) would work
> if we are using IPv6 and the MTU is the statutory minimum of 1,280 bytes.
> Indeed, in the latter case, I get a maximum reassembled UDP packet size of
> 2,446 bytes if only two fragments are supported. That seems to me to be
> rather small.
>
> I would like to propose instead that we specify that an implementation
> must support a minimum of 3 fragments and a minimum reassembled size of
> 3,600 bytes. This fits nicely with the 1,280 byte minimum MTU over IPv6,
> allowing for a total of 66 bytes of extra overhead (e.g., 22 bytes of
> per-fragment UDP options in each fragment). If the MTU is larger, as is
> typically the case, one of the three fragments would not be full size,
> which is not a problem.
>
> I would appreciate hearing from the WG whether this change would be
> acceptable.
>
> Feel free to comment on the list or on github
> <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/52>.
>
> Thanks and regards,
>
> Mike Heard
>