MD/CMH: Change minimum reassembled UDP datagram size from 3000 to 2926

[Mike-Heard]

In https://mailarchive.ietf.org/arch/msg/tsvwg/dxL8px2Gri30qw2xTBes5UQohM4/, 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)

I also get 2926 for IPv4 and 2886 for IPv6, if we include the reconstituted UDP header in the total. Not a big deal, of course, but for internal consistency I suggest s/3000/2926/.

[Mike-Heard]

An alternate update could be:

s/for a total of at least 3,000 bytes/which with a typical Ethernet MTU will not require more than 3,000 bytes/

[jtouch]

Agreed there’s a terminology disconnect here.

This went back and forth a lot. UDP calculates its MSS based on what IP reports (IP MTU) and what the it knows about the IP and UDP fixed and optional headers for that socket. Perhaps what we should say is “at least 2 fragments, which never requires more than 3,000B of receiver storage of the incoming IP packets”??

We really can’t say what the user will end up getting, unless we make THAT the edict - if so, a round number would be a lot nicer (e.g., 2KB of user data? Or 2500B of user data?)

[jtouch]

From CM Heard:

The number 2926 turns out to be what is possible with two fragments. Note that Martin Duke (who originally raised this issue) said "(To be clear, I can live with 3000)". Based on that, I'm fine with your proposed wording.

[Mike-Heard]

An alternate update could be:

s/for a total of at least 3,000 bytes/which with a typical Ethernet MTU will not require more than 3,000 bytes/

This change is now in Section 11.4 of the editor's copy of -33.

[Mike-Heard]

Additionally, the following change was added to Section 11.6 (added text in bold):

>> Endpoints supporting UDP options MUST support a local MRDS of at least 3,000 bytes. This is sufficient to allow for two maximum size fragments with the typical Ethernet MTU of 1,500 bytes, in accordance with the requirements in Section 11.4.

[jtouch]

An alternate update could be: s/for a total of at least 3,000 bytes/which with a typical Ethernet MTU will not require more than 3,000 bytes/

This change is now in Section 11.4 of the editor's copy of -33.

Shouldn't this also refer to "not require more than 1500 bytes each for two Ethernet frames"?

[Mike-Heard]

Shouldn't this also refer to "not require more than 1500 bytes each for two Ethernet frames"?

I don't think so, if we want to accommodate MTUs larger than 1500 bytes.

After reflection, the text in Section 11.4 of the editor's copy has been reverted to what was in -32 and now reads:

>> Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least two fragments, for a total of at least 3,000 bytes (see MRDS in Section 11.6).

This does not stipulate that fragments are limited to 1,500 bytes, only that an implementation must accept at least two of them and that when reassembled they must fit in a 3,000 byte buffer.

The text added to Section 11.6 still reads:

>> Endpoints supporting UDP options MUST support a local MRDS of at least 3,000 bytes. This is sufficient to allow for two maximum size fragments with the typical Ethernet MTU of 1,500 bytes, in accordance with the requirements in Section 11.4.

I think this addresses Martin's comment. But if it does not work for you, please let me know what will.

[jtouch]

I thought the original idea was that the original UDP packet could be split into two UDP fragments that each would fit into a 1500B Ethernet frame, where the onus is on each UDP socket to figure out what that means in terms of user payload vs UDP option area, both overall and per-fragment.

[jtouch]

I.e., this was never about Ethernet MTUs larger than 1500 - that's largely DOA except in datacenters AFIACT. It was more inspired by the difference between IPv6 EMTU_R (1500B) and EMTU_S (1280B).

[Mike-Heard]

I.e., this was never about Ethernet MTUs larger than 1500 - that's largely DOA except in datacenters AFIACT. It was more inspired by the difference between IPv6 EMTU_R (1500B) and EMTU_S (1280B).

Thanks for this, it's a very good point, and we do indeed have a gap. It took me a while to see it.

I thought the original idea was that the original UDP packet could be split into two UDP fragments that each would fit into a 1500B Ethernet frame, where the onus is on each UDP socket to figure out what that means in terms of user payload vs UDP option area, both overall and per-fragment.

I would put it a bit differently. Since the original (pre-fragmentation or post-reassembly) UDP packet includes the UDP header and any per-datagram options, the user/application must take that into account when composing its send request (which includes both the payload data and option requests, both per-datagram and per-fragment) to ensure that the pre-fragmentation UDP packet size is not more that the larger of 3,000 bytes or the MRDS size reported by the remote end. The onus is then on the UDP socket to figure out how to cut the pre-fragmentation UDP packet into fragments that all fit within the estimated path MTU after all per-fragment UDP options (including FRAG itself) and all lower-layer headers and options have been added to the UDP fragments.

The problem is that if the size of the original UDP packet is 3,000 bytes (or the MRDS size reported by the remote end, which must not be smaller) then the number of fragments will be greater than 2 if the MTU is 1,500 bytes. Oops.

I would have to review the mailing list archives to be certain, but my recollection of the mailing list discussion is that:

1. The decision to allow an implementation to max out at two fragments was done to limit the implementation complexity of the reassembly logic.

2. The decision to require an implementation to have a reassembly buffer of 3,000 bytes was made to ensure that an it could accommodate two maximum size fragments when the MTU is the standard Ethernet 1500-byte payload size.

I think that we need to revisit this decision. We should start with the MRDS size that we want implementations to support (maybe 4,096 bytes to match the default EDNS(0) buffer size), and then work from the minimum path MTU that we are likely to encounter to determine the number of fragments that we need to reassemble. If we use 1280 as the minimum path MTU for IPv6 and 1,500 as minimum likely MTU for IPv4, then the number of packets that will need to be reassembled is going to be at least 3. It will be even larger if we use 576 as minimum likely MTU for IPv4.

I will note that both the IPv4 and IPv6 fragmentation and reassembly specs are silent on how many fragments must be handled. IPv4 implementations are required to reassemble a 576-byte IPv4 datagram when the path MTU is as small as 68 bytes. That's 70 fragments.

I won't make any more edits related to this issue until I get a clearer idea of which direction we should go.

[Mike-Heard]

Proposal for 3 frags / 3,600 bytes sent to the mailing list, see: https://mailarchive.ietf.org/arch/msg/tsvwg/YHqTpgGysV2nnxYltQQ9Gi5Nsrw/

[jtouch]

I think this is being overthought. Here's the goal, in short:

• a receiver MUST be capable of reassembling at minimum of two UDP fragments into a single UDP datagram, in which each fragment does not exceed an IP MTU of 1500B.

We're not working backwards from anything specific; if we were, it would be impossible to indicate the sizes of the original UDP datagram or its fragments because we are not intending to directly constrain the options used (either per fragment or per datagram). We're working forwards from the minimum reassembly size at the receiver, which is two packets.

If we want to make it three, that's fine too, but it doesn't change how it's specified (above, except to change "two" to "three") or that we need to stick to the IP MTU sizes (the way TCP MSS is defined). The onus is on the sender/receiver to figure out how much user data space is available, either per fragment or per original datagram - just as it is with TCP.

[Mike-Heard]

I think this is being overthought. Here's the goal, in short:

• a receiver MUST be capable of reassembling at minimum of two UDP fragments into a single UDP datagram, in which each fragment does not exceed an IP MTU of 1500B.

After a couple of days of reflection, I'd say rather that what is now in the spec (2 frags / 3,000 bytes) was underthought, since it is not possible to achieve 3,000 bytes with a 1,500 byte MTU and 2 frags. It actually takes 3 frags to do that; what is achievable with 2 frags is strictly less, as Martin pointed out. An application that has received an MRDS size of 3,000 is not guaranteed to be able to successfully send that much unless the path MTU is greater than 1,500 bytes -- which doesn't usually happen outside of data centers. My contention is that we are doing a disservice to the users of the spec if we do not at least specify some numbers that are actually achievable. Anyway, that's my takeaway from Martin's comment.

We're not working backwards from anything specific; if we were, it would be impossible to indicate the sizes of the original UDP datagram or its fragments because we are not intending to directly constrain the options used (either per fragment or per datagram). We're working forwards from the minimum reassembly size at the receiver, which is two packets.

If we want to make it three, that's fine too, but it doesn't change how it's specified (above, except to change "two" to "three") or that we need to stick to the IP MTU sizes (the way TCP MSS is defined). The onus is on the sender/receiver to figure out how much user data space is available, either per fragment or per original datagram - just as it is with TCP.

I think we'll end up with a more useable spec if we raise the limit to three frags. That would allow the current 3,000 byte limit on reassembled packet size to be achievable in practice.

And taking that one step further: if we believe that MTUs of less that the IPv6 statutory minimum of 1,280 bytes are uncommon, there should be no problem raising the reassembly limit up to 3,600 bytes.

Granted, none of this spares the implementation the burden of checking two limits (total number of bytes reassembled, and number of fragments that will be created), but getting the two limits to mesh better with each other with help make the spec work better for those who use it -- especially those implementations that elect to use the IPv6 minimum MTU when unable to determine the actual path MTU.

[jtouch]

The current text says:

Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least 2 fragments, for a total of at least 3,000 bytes (see MRDS in Section 11.6).

The number is a storage requirement that was always based on 2 1500B IP ethernet payloads. It was never based on a requirement of a 3,000 byte user data payload.

We can pick a different number of IP MTUs, but I believe that this doc - like RFC6991 - should describe UDP in terms of how much IP space is expected at the receiver and (if additionally desired) how many fragments should be generated at the sender.

If each sends 1500B IP, how much is left for each UDP fragment depends on the IP headers, IP options, UDP base header (8B), original datagram UDP options, and per fragment options (including the FRAG option itself). We know the minimums of those, but we don't know actuals - only the sender knows what will actually be sent and always derates the IP MTU by the IP headers and options and UDP headers and options.

Picking a specific number as the user payload of the reassembled fragments is not possible and thus not a relevant requirement if we limit the number of fragments. So we either say "what ends up in 2 Ethernet frames" or we say "at least N bytes user payload", but the latter is something a receiver can't code to.

So again, I don't think it matters whether it's 2 or 3 (or 4), but we should define this requirement in terms of a finite number of Ethernet 1500B frames as an upper bound (at the receiver), and - if we want to limit the number of fragments - indicate that number as a requirement on the sender. The number of user bytes transferred doesn't belong in a requirement.

[Mike-Heard]

The number of user bytes transferred doesn't belong in a requirement.

I disagree. The definition of MRDS already includes the number of user bytes transferred (bold text was added in Issue #54):

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.

It has been this way since -14 (minus the bold text, which was only a clarification). And this is as it should be, since the number of user bytes transferred is what is of direct interest to the user/application, the entity that receives and acts upon the MRDS value.

I get the sense that we are talking at cross-purposes. So let me cut to the chase and ask the direct question: if the WG agrees, would you be open to the following changes:

Section 11.4 (changed text in bold):

>> Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least three fragments, for a total of at least 3,600 bytes (see MRDS in Section 11.6)

Section 11.4 (changed text in bold:

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

This is the question that I put to the WG in https://mailarchive.ietf.org/arch/msg/tsvwg/YHqTpgGysV2nnxYltQQ9Gi5Nsrw/

[jtouch]

We're not specifying the number in a requirement. Only the receiver can calculate MRDS - that's why the receiver needs to report it directly to the sender. However, note that MRDS doesn't indicate the user data payload - it indicates the entire datagram, UDP header and UDP options included. It has to calculate that. The 2 x 1500B is set as a requirement as an upper bound of the space available.

The second requirement does not imply the first. The. first should be:

Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least three fragments, for a total reassembled UDP datagram, including UDP header and per-datagram options, of at least 3,600 bytes (see MRDS in Section 11.6).

But this won't work if MDS is 576 because it would require more than three fragments. So then, your first requirement would need to say

Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least three MDS fragments, for a reassembled total of at least 3,600 bytes (see MRDS in Section 11.6), whichever is smaller.

I.e., if we're limiting to 3 fragments, then we can't assume we'll always end up with 3,600 bytes.

--

This brings me to the ultimate question: are we trying to ensure a size or limit the number of fragments? doing both might not have the desired result.

[Mike-Heard]

[Unfortunately, I failed to cc tsvwg@ietf.org on the initial transmission of my message Resolving UDP Options Issue #52. As result, Gorry's reply did not make it to the list. I am adding it to the discussion here so that it is part of the public record. --cmh]

---------- Forwarded message --------- From: Gorry Fairhurst gorry@erg.abdn.ac.uk Date: Tue, Aug 6, 2024 at 2:07 AM Subject: Re: Resolving UDP Options Issue #52 To: C. M. Heard heard@pobox.com Cc: draft-ietf-tsvwg-udp-options.all@ietf.org

On 05/08/2024 14:55, C. M. Heard 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 think something happened that I misssed, sorry.

I opened Issue #52 on April 22, 2024 to address this comment, with a proposal to change the limit from 3,000 bytes to 2,926 bytes.

That was fine, reducing the size to what sensibly fits is a good idea.

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

Yes, and the goal I recall was to ensure we never made more than two fragments with a common Ethernet MTU (plus overheads!). The rationale being that the code to reassemble a start and end fragment is trivial, but adding a middle fragment significantly increases the code that is exercised, and required you check for excessive number of middle fragments, etc.

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. I see that, it wasn't our starting point, but that size is credible.

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.

Maybe what fits in two IPv6 MinMTU packets is OK as a minimum then? I could live with that. This allows more for protocol headers than I'd first thought - but it's a conservative starting point.

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.

Thanks and regards,

Mike Heard

Happy to comment on github, and yes we ought to ask the WG, but I'd rather thrash-out if we really need a minimum of 3 fragments. Gorry

[Mike-Heard]

Joe writes:

Only the receiver can calculate MRDS - that's why the receiver needs to report it directly to the sender. However, note that MRDS doesn't indicate the user data payload - it indicates the entire datagram, UDP header and UDP options included. It has to calculate that. The [3 x 1200B] is set as a requirement as an upper bound of the space available.

The second [3 x 1200B] requirement does not imply the first. The. first should be:

Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least three fragments, for a total reassembled UDP datagram size, including UDP header and per-datagram options, of at least 3,600 bytes (see MRDS in Section 11.6).

But this won't work if MDS is 576 because it would require more than three fragments. So then, your first requirement would need to say

Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least three MDS fragments, for a total reassembled UDP datagram size, including UDP header and per-datagram options, of at least 3,600 bytes (see MRDS in Section 11.6), whichever is smaller.

I.e., if we're limiting to 3 fragments, then we can't assume we'll always end up with 3,600 bytes.

Correct (but note that the italic text is not an exact quote, it has presumed corrections). The actual MRDS size depends on the MTU in the direction from the sender to the receiver that generates the MRDS value. The MDS value is based on the receiver's estimate of the MTU. One of our problems is that only the sender can run PLPMTUD and know that value for sure. In the absence of specific knowledge, RFC 8085 tells us to assume that the MTU is the smaller of 576 bytes and the first-hop MTU for IPv4 and 1280 bytes for IPv6. The corresponding MDS sizes are 548 bytes and 1232 bytes, respectively. I will note that our colleagues in DNSOP seem to believe that the low MTU for IPv4 is out of date; see draft-ietf-dnsop-avoid-fragmentation.

This brings me to the ultimate question: are we trying to ensure a size or limit the number of fragments? doing both might not have the desired result.

Agreed, doing both is hard. If both need to be controlled, my sense is that an application sending a UPD datagram needs to be told (directly or indirectly) by the remote end not only what the MRDS size is but also how many fragments the remote end supports. We have an option for the former but not the latter. If we are not going to add an option to specify the number of fragments (or modify and existing one to do so), we probably need to provide some advice to the generator of the MRDS option on how to calculate the MRDS size it advertises (based on how many frags it supports and what MTU it assumes or its reassembly buffer size, whichever is smaller) and also to the consumer of the MRDS option on how to size its response fragments (based on the advertised MRDS size and the path MTU information available to it, if any, possibly including the advertised MDS value).

Gorry writes:

Yes, and the goal I recall was to ensure we never made more than two fragments with a common Ethernet MTU (plus overheads!). The rationale being that the code to reassemble a start and end fragment is trivial, but adding a middle fragment significantly increases the code that is exercised, and required you check for excessive number of middle fragments, etc.

I do not wish to revisit a WG decision that is firmly finalized, but I do note that neither the IPv4 nor the IPv6 specs have a specific bound on the number of fragments that an endpoint must reassemble. Note that for IPv4 an implementation would need to be able to reassemble 70 fragments in order to receive a 576-byte IP datagram over a link with an MTU of 68 bytes. A lower limit of 2 fragments with an MTU of 576 bytes allows for a reassembled UDP packet of 1078 bytes:

MRDS_size = ((MDS_size - 12) * NumFrags) - 2 - PerFragUdpOptions + 8

My sense is that despite what is said in RFC 8085, it would be a disservice to the community to base the design on a minimum MTU of 576 (or an MDS of 548). A more realistic (but still very conservative) MTU would be 1280 (corresponding to an MDS of 1232). In that case 2 frags / 2400 bytes or 3 frags / 3600 bytes would be defensible, but we would still need to add some advice in Section 11.6 that advertising larger MRDS (or assuming a smaller MDS) would resulting in needing to be able to reassemble more fragments. Or, as an alternative, we could providing a direct means to advertise the number of fragments that can be reassembled.

Advice on WG preferences is requested. Apologies that this discussion is taking a long time to converge.

[jtouch]

Agreed - FWIW, this is why I believe the appropriate recommendation should be to make sure

A) the receiver can reassemble up to two 1500B IP packets (the largest MTU over typical Ethernet) and can reassemble at least 2 fragments,

B) the sender should send up to 2 fragments of whatever MTU it determines //unless the receiver indicates support for more than 2 fragments using MRNS (see below)

That way the receiver has space for the max, but both sides don't expect more than 2 fragments in the general case.

Yes, this might mean we should have a new MRNS option (max receiver number of segments) to allow the receiver to indicate capability/willingness to allow more than 2 fragments. The sender doesn't have to reply or indicate anything; it can simply use that info with its designed-in capability to determine how many fragments to send.

Would that work?

[jtouch]

Note that we can't simply get MRNS from MRDS / MDS because the receiver or sender may still want to limit the number of fragments used.

FWIW, we COULD set MRNS as a field of the MRDS option, making the option 1 byte longer (it's unlikely it would ever be necessary to have more than 256 fragments), or by "stealing" bits from the MRDS option (e.g., assuming it is always indicated as a number divisible by 8, we would have 3 bits to indicate the number of fragments). Just a thought.

[Mike-Heard]

Agreed - FWIW, this is why I believe the appropriate recommendation should be to make sure

A) the receiver can reassemble up to two 1500B IP packets (the largest MTU over typical Ethernet) and can reassemble at least 2 fragments,

This would allow the current text in 11.4 to stay as is, except for adding the words "whichever is larger" as previously suggested. That takes care of the issue raised by Martin Duke.

B) the sender should send up to 2 fragments of whatever MTU it determines //unless the receiver indicates support for more than 2 fragments using MRNS (see below)

That way the receiver has space for the max, but both sides don't expect more than 2 fragments in the general case.

Yes, this might mean we should have a new MRNS option (max receiver number of segments) to allow the receiver to indicate capability/willingness to allow more than 2 fragments. The sender doesn't have to reply or indicate anything; it can simply use that info with its designed-in capability to determine how many fragments to send.

Would that work?

Yes, it would. It puts the responsibilities where they belong: the receiver is the only one that knows what its MRDS and MNRS values are. The sender needs both values in order to figure out whether a message that it wants to send will fit and how it should be fragmented if it needs to be fragmented. If the sender has not seen any MRDS or MNRS options, it just uses the defaults of 3,000 and 2 respectively.

Note that we can't simply get MRNS from MRDS / MDS because the receiver or sender may still want to limit the number of fragments used.

Yes, and anyway MDS as reported by the receiver is (based on) the receiver's estimate as to what the sender-to-receiver MTU is. Only the sender can get accurate information (by running PLPMTUD)

FWIW, we COULD set MRNS as a field of the MRDS option, making the option 1 byte longer (it's unlikely it would ever be necessary to have more than 256 fragments), or by "stealing" bits from the MRDS option (e.g., assuming it is always indicated as a number divisible by 8, we would have 3 bits to indicate the number of fragments). Just a thought.

While it would work to make these separate options, I see no particular benefit. I'd like to think about the details.

And there is one other question that I have. How long is the information sent in MRDS/MNRS considered valid? To me that seems to be the province of the upper layer protocol. For request/response applications such as DNS, I'd say one transaction.

I'm going to sleep on this and do my best to have a concrete proposal for review by COB tomorrow. I note that most of the surgery will be to 11.6; I wonder if it we should open a new issue for that. We could point to the discussion here.

[jtouch]

As to how long the info is valid, that would be as long as you think you're talking to the same endpoint. That might be longer than one transaction (e.g., it might be cached with a socket at the host), but if you really care you need to create a connection identifier cookie of some sort to keep exchanging because there are no guarantees that destination IP/port is immutable over any period of time. That's far outside the scope of what we want to do in this spec, at least at this time.

[Mike-Heard]

OK. To address this issue I propose the following update (changes in bold):

OLD:

>> Endpoints supporting UDP options MUST be capable of fragmenting and reassembling at least 2 fragments, for a total of at least 3,000 bytes (see MRDS in Section 11.6).

NEW:

>> 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 of 2,926 bytes for IPv4 and 2,886 bytes for IPv6. For further discussion see Section 11.6.

Note that the number of fragments required to be reassembled remains at two, per Gorry's comment.

I have opened Issue #63 to deal with the proposed updates to MRDS.

[jtouch]

I strongly suggest NOT providing the actual numbers in this document, because they have NO meaning except as a possible upper bound for pub discussions, IMO. We should indicate how they're determined but remind everyone that the onus is always on the transmitter and receiver to figure this all out, based not only on the base headers but also the actual options in use.

If we put in these numbers, someone is going to think they CAN get that much data through, and that's always a bad assumption.

[Mike-Heard]

I strongly suggest NOT providing the actual numbers in this document, because they have NO meaning except as a possible upper bound for pub discussions, IMO.

Strictly speaking we do not need to provide actual numbers here in Section 11.4, but IMO we must provide numbers for the minimum MRDS size in Section 11.6. Putting the numbers here supports the discussion of MRDS size in Section 11.6, at least if the text proposed for that section in Issue #63 is accepted in its present form.

We should indicate how they're determined but remind everyone that the onus is always on the transmitter and receiver to figure this all out, based not only on the base headers but also the actual options in use.

If we put in these numbers, someone is going to think they CAN get that much data through, and that's always a bad assumption.

The proposed text in Issue #63 tells an endpoint how to calculate what it will get, and makes it explicit how that depends on the PMTU and the total size of the options/extension headers that are used used.

I've updated the proposed text with the italicized note shown below in order to help prevent the reader from erroneously concluding that the numbers 2,926 and 2,886 will always get through.

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

If this is still unsatisfactory, it would be helpful to suggest an alternate means of making this part of Section 11.4 and the revised Section 11.6 tell a coherent story.

[jtouch]

Although I find this text generally reasonable, I strongly urge NOT putting the minimum in both places. At most they should only be in Section 11.6. However, again, I do not believe putting these numbers in is appropriate because there are really a few different values - one for IPv4 assuming 576B IP MTU, one for IPv6 assuming 1280B IP MTU, and two more for IPv4 and IPv6 both assuming a 1500B IP MTU. There's little point in indicating what these might be limited to in an RFC; in practice, the endpoint needs to figure these out based on the actual options being used anyway. Putting in actual numbers based on potentially rare if not completely irrelevant cases will only cause confusion.

[Mike-Heard]

Points taken, though I will note that the numbers serve somewhat different purposes in the two sections. In Section 11.4 they serve to make explicit the minimum size UDP packet that an implementation is required to fragment and reassemble, while in Section 11.6 they serve to make explicit the minimum values that an endpoint must advertise in the MRDS option. As you may have noted, I requested feedback from the WG on the mailing list (https://mailarchive.ietf.org/arch/msg/tsvwg/_ix9bANKLfWfwRVHXIQFJdqf17Y/). I'll revisit this matter in a couple of days after seeing that the WG has to say (if anything) and thinking on it. Many thanks for the feedback, it's much appreciated.

[auerswal]

I'd like to point out a small nit in the email sent to the WG mailing list (https://mailarchive.ietf.org/arch/msg/tsvwg/_ix9bANKLfWfwRVHXIQFJdqf17Y/):

In the last changed paragraph, concerning no received MRDS option, a >> marker is used without an uppercase keyword. Instead, a lower case must is used.

I'd like to suggest to either use uppercase MUST or to remove the >> marker.

[Mike-Heard]

I'd like to point out a small nit in the email sent to the WG mailing list (https://mailarchive.ietf.org/arch/msg/tsvwg/_ix9bANKLfWfwRVHXIQFJdqf17Y/):

In the last changed paragraph, concerning no received MRDS option, a >> marker is used without an uppercase keyword. Instead, a lower case must is used.

I'd like to suggest to either use uppercase MUST or to remove the >> marker.

Good catch, thank you. I will change the lowercase "must" to an uppercase "MUST" in the editor's copy of -33 and update Issue #63. It's very helpful to catch as many these things as possible prior to submission of the draft.

[Mike-Heard]

Although I find this text generally reasonable, I strongly urge NOT putting the minimum in both places.

No one else has expressed an opinion, so I changed this

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

to

>> 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. For further details, please see Section 11.6.

in the editor's copy while leaving the new text in 11.6 (see #63) as previously proposed.

Will this resolve your objections? If so, I think this stage of edits is done.

[jtouch]

Yup. Works for me.

[martinduke]

FWIW, I'm fine with where you guys landed on this.