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]
