Fragmentation, while undesirable, is unavoidable. As long as we have a fixed upper bound on MTU (which IP does) and use IP inside IP (sometimes with intervening layers), there will always be a point at which a payload becomes too big to transit whole. Even pushing that info back to the source may not help; the headers alone add up.
The alternative would have been to say that the payload stays the same size even while we add headers - as Ethernet does. Strictly, Ethernet has no upper bound on packet size, which makes it just fail at some point. IP avoids that at this cost - of reassembly. Concerns about that don’t make it go away, nor do they avoid the consequence that we should avoid unnecessary reordering where possible because of its impact. I appreciate keeping problems upstream, but fragmenting is writing a check that *requires* downstream to cash it. Joe > On Nov 10, 2025, at 9:00 AM, Richard Patterson <[email protected]> wrote: > > Necroing and piggybacking on this old thread to expand on my > at-the-mic-comment about concerns around IP fragmentation. > > My concern is that with IPv4aaS technologies such as 464XLAT, MAP and > lw4over6, we have pushed NAT64 translation/encapsulation down to the mobile > UE and fixed-line CEs; fragmented packets--which are sometimes unavoidable > with the additional encapsulation in or translation to IPv6--require > reassembling, and depending on the implementation that will at best consume > more resources and at worst be consistently dropped if the hashing is > consistent across retransmits. > > I realise the argument about it consuming more resources and effort on the CE > Router or UE is just me saying that I'd rather keep that problem upstream, so > I'm more concerned about the risk where fragments are consistently dropped > having a permanent impact on packet delivery. > > -Rich > > On Thu, 13 Mar 2025 at 00:31, [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> wrote: >> Fragment reassembly is one reason. Another non-transport reason is IPsec >> replay. But in both cases, it’s not just ordering that matters; it varies >> depending on whether the stream is reordered in isolation or different >> reordered streams are concurrent. >> >> - in all cases, reordering matters within in a ’stream’, but the definition >> of ’stream’ varies >> IPsec = IP addresses + SPI >> IP reassembly = IP addresses + FragID >> >> - out of order impact differs >> IPsec = >> reordering within a stream causes later packets of the same >> stream to the dropped as replay attacks >> interleaving of different reordered streams has no new impact >> over interleaving of order-preserving streams >> IPreassembly = >> reordering within a stream set may or may not have any impact >> over interleaving of order preserving streams >> interleaving of different reordered streams consumes more >> resources, as each pending stream requires a max-receive buffer >> >> Otherwise, I can’t see a good reason either. >> >> Joe >> >> — >> Dr. Joe Touch, temporal epistemologist >> www.strayalpha.com <http://www.strayalpha.com/> >> >>> On Mar 12, 2025, at 5:10 PM, Joel Halpern <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I am trying to think why IP (as distinct from TCP / QUIC / ..) would care >>> about ordering at all. I suppose the corner case of reordered fragments >>> could be considered relevant to IP. But mostly, this seems to belong at >>> transport, not IP. >>> >>> Yours, >>> >>> Joel >>> >>> PS: I think the wording in the draft could be clearer that this is data for >>> input to L2 standards bodies, not recommendations for behavior at L2. >>> >>> On 3/12/2025 8:02 PM, Greg White wrote: >>>> Thanks Joe. >>>> >>>> Yes, that could be case, but IMO it would be out of scope for the draft to >>>> explore non-IP use cases. >>>> >>>> Perhaps the goal of this document could be described as gathering the >>>> current wisdom around the implications, positive and negative, of L2 >>>> resequencing on IP. >>>> >>>> Greg >>>> >>>>> On Mar 12, 2025, at 5:32 PM, [email protected] >>>>> <mailto:[email protected]> wrote: >>>>> >>>>> Hi Greg, >>>>> >>>>> FWIW, it might be useful to note that some L2s maintain ordering for >>>>> their own purposes, e.g., ATM did so to simplify fragmentation and >>>>> reassembly in its own protocol layers. Others may rely on in-order >>>>> delivery for control messages (do Ethernet BPDUs require this?). >>>>> >>>>> I.e., it’s not always something L2 does for IP… >>>>> >>>>> Joe >>>>> >>>>> — >>>>> Dr. Joe Touch, temporal epistemologist >>>>> www.strayalpha.com <http://www.strayalpha.com/> >>>>> >>>>>> On Mar 11, 2025, at 1:05 PM, Greg White >>>>>> <[email protected]> >>>>>> <mailto:[email protected]> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> There was a recent discussion on the QUIC and TSVWG mailing lists* >>>>>> regarding the somewhat common implementation in L2 networks of >>>>>> guaranteeing in-order delivery by delaying higher-sequenced L2 frames >>>>>> while waiting for a later arriving lower-sequenced frame. This practice >>>>>> has been important historically, but brings multiple costs due to >>>>>> implementation complexity and L2 protocol complexity. In addition, the >>>>>> re-sequencing may end up doing more harm than good, since it is >>>>>> generally done without knowledge of the higher-layer protocol contexts >>>>>> (e.g. the late packet that triggers the delay might be for a different >>>>>> TCP connection than the ones that get delayed). Since modern TCPs and >>>>>> many QUIC implementations are tolerant of some reordering, a few of us >>>>>> thought it would be worthwhile to have a broader discussion and see if >>>>>> we could agree on new guidance that the IETF could provide to L2 >>>>>> standards orgs. Intarea was suggested as being the most appropriate WG >>>>>> to bring the discussion to. >>>>>> >>>>>> To that end, we've written a draft. The datatracker version (draft-00) >>>>>> is linked below, but the version on GitHub is more up-to-date. >>>>>> https://gwhitecl.github.io/draft-white-intarea-reordering/draft-white-intarea-reordering.html >>>>>> >>>>>> There is a short slot on the agenda on Monday to introduce the draft and >>>>>> get reactions. >>>>>> >>>>>> Best regards, >>>>>> Greg >>>>>> >>>>>> * >>>>>> https://mailarchive.ietf.org/arch/browse/tsvwg/?gbt=1&q=%22Robustness%20to%20packet%20reordering%22 >>>>>> >>>>>> >>>>>> >>>>>> On 3/3/25, 3:56 PM, "[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected]> >>>>>> <mailto:[email protected]>" <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected]> >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> A new version of Internet-Draft draft-white-intarea-reordering-00.txt >>>>>> has been >>>>>> successfully submitted by Greg White and posted to the >>>>>> IETF repository. >>>>>> >>>>>> >>>>>> Name: draft-white-intarea-reordering >>>>>> Revision: 00 >>>>>> Title: Proposal for Updates to Guidance on Packet Reordering >>>>>> Date: 2025-03-03 >>>>>> Group: Individual Submission >>>>>> Pages: 6 >>>>>> URL: >>>>>> https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.txt >>>>>> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.txt> >>>>>> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.txt> >>>>>> Status: https://datatracker.ietf.org/doc/draft-white-intarea-reordering/ >>>>>> <https://datatracker.ietf.org/doc/draft-white-intarea-reordering/> >>>>>> <https://datatracker.ietf.org/doc/draft-white-intarea-reordering/> >>>>>> HTML: >>>>>> https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.html >>>>>> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.html> >>>>>> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.html> >>>>>> HTMLized: >>>>>> https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering >>>>>> <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering> >>>>>> <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Abstract: >>>>>> >>>>>> >>>>>> Several link technology standards mandate that equipment guarantee >>>>>> in-order delivery of layer 2 frames, apparently due to a belief that >>>>>> this is required by higher layer protocols. In addition, certain >>>>>> link types can introduce out-of-order arrivals at the end of the >>>>>> layer 2 link, which the receiving equipment is required to rectify by >>>>>> delaying higher sequenced frames until all lower sequenced frames can >>>>>> be delivered or are deemed lost. The delaying of higher sequenced >>>>>> frames is generally done without any knowledge of the higher layer >>>>>> protocols in use, let alone any knowledge of higher layer protocol >>>>>> contexts (e.g. TCP connections) in the case that the layer 2 link is >>>>>> carrying a multiplex of such contexts. It could, for example, be the >>>>>> case that all of the higher sequenced frames being delayed are >>>>>> carrying packets for different layer 4 contexts than a single lower- >>>>>> sequenced frame that triggered the delay. The result is that this >>>>>> "re-sequencing" operation can introduce delays that result in >>>>>> degradation of performance rather than improving it. Moreover, >>>>>> modern, performant TCP and QUIC implementations support features that >>>>>> significantly improve their tolerance to out-of-order delivery. >>>>>> >>>>>> >>>>>> This draft is intended to promote an analysis and discussion of the >>>>>> sensitivity of modern protocols to out-of-order delivery, and to >>>>>> potentially develop new guidance to layer 2 technology standards >>>>>> regarding the need to assure in-order delivery. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Int-area mailing list -- [email protected] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Int-area mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >> >> _______________________________________________ >> Int-area mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
