Thanks for bringing this to the list. Is there evidence that broken reassembly implementations exist? If so, where are they? If this is a widespread problem, then we’ll probably need some strong guidance to avoid issues, but if it is unique to some obscure piece of gear then perhaps not.
Since resequencing adds cost and complexity to L2 equipment and is harmful for the vast majority of traffic, I don’t think it is reasonable to require all L2 links to resequence all traffic just because there is a broken frag reassembly implementation in some isolated case. Building part of the IP fragmentation reassembly engine (fragment sequencing) into L2 is a possible workaround, but I’d hate for the IETF to be recommending it as a general solution. -Greg From: "[email protected]" <[email protected]> Date: Tuesday, November 11, 2025 at 6:35 AM To: Richard Patterson <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [Int-area] Re: New Version Notification for draft-white-intarea-reordering-00.txt Sorry - I wasn’t sure from the last part. As long as it’s clear… Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com On Nov 10, 2025, at 10:08 AM, Richard Patterson <[email protected]> wrote: We're saying the same thing right? Fragmentation sucks but is unavoidable, and this document should exclude fragments from its relaxing of the advice against reordering? (Sorry, it was just your last paragraph that confused me.) On Mon, 10 Nov 2025, 17:27 [email protected]<mailto:[email protected]>, <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<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]
