Hi, Greg, My point is different; I’m not suggesting getting into the details - the point is that IP isn’t the only reason L2s try to enforce ordering.
If an L2 needs ordering for other reasons, then that’s just the “cost of using that L2”, not something that the IP layer should suggest can/should be relaxed. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Mar 12, 2025, at 5:02 PM, Greg White <[email protected]> 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] 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 >> >>> On Mar 11, 2025, at 1:05 PM, Greg White >>> <[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]>" <[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> >>> Status: 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> >>> HTMLized: >>> 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] >>> To unsubscribe send an email to [email protected] >>
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
