Enhance MRDS (or add another option) to advertise the maximum number of fragments that can be reassembled

[Mike-Heard]

Currently, MRDS (Section 11.6) specifies only the maximum datagram size that can be reassembled; it is silent regarding the number of fragments that can be reassembled, and there is at present no other means to advertise that information.

The maximum datagram size that can be reassembled by the receiving end is not sufficient information to allow a sender to determine whether a given pre-fragmentation UDP packet can actually be handled be the receiving end; the sender also needs to know how many fragments that the receiving end can reassemble. If MRDS_size is the number of bytes in the largest reassembled datagram that the receiver can handle and MRDS_segs is the maximum number of UDP fragments that the receiver can reassemble, then the size of the largest pre-fragmentation UDP packet (including the UDP header and per-datagram UDP options) that can be successfully sent is:

MIN ( (PMTU - IP_Hdr_size - UDP_Hdr_Size - 12) * MRDS_segs - 2 - Total_Per_Frag_Options + 8, MRDS_Size )

where IP_Hdr_size is the size of the IPv4 or IPv6 header and all IP options and extension headers and Total_Per_Frag_Options is the total size of IP options and extension headers and the total size of the per-fragment UDP options, not including OCS and FRAG, that are sent in the series of fragments.

The sender can determine PMTU either by running DPLPMTUD, local configuration, or using the minimum values specified in RFC 8085 (smaller of 576 or first-hop MTU for IPv6, smaller of 1280 or first-hop MTU for IPv6). But it cannot determine MRDS_size or MRDS_segs; those parameters have to be provided by the receiver.

To address this issue, I propose the following changes to Section 11.6:

OLD:

The Maximum Reassembled Datagram Size (MRDS, Kind=5) option is a 16-bit indicator of the largest reassembled UDP datagram that can be received. MRDS 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.

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

      Figure 14   UDP MRDS option format

>> Endpoints supporting UDP options MUST support a local MRDS of at least 3,000 bytes.

NEW:

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.

This proposal was a result of discussion that took place in connection with Issue #52. Please see that issue for the parallel changes that are proposed for Section 11.4. That is where "2,926 bytes for IPv4 and 2,886 bytes for IPv6" came from.

[Mike-Heard]

P.S. I didn't discuss adding a separate option to allow a receiver to send just the number of fragments that it would support. That approach will work, but it has the disadvantage of being bulkier with no upside that was apparent to me. Please set me straight if you think that is erroneous.

[Mike-Heard]

Thanks to Erik Auerswald for catching this typo (see comment in Issue #52):

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

The imperative MUST was not in uppercase.