I’m open to different terminology if it improves clarity. I’ve not done an exhaustive study of the RFC series, but there does seem to be some precedent for “reordering” in the way we’ve defined it (most notably RFC4737) and “resequencing” the way we’ve defined it (e.g. RFC892, RFC1122, RFC1193, RFC7325). But I also see that RFC7325 seems to use “reordering” both for packets getting out of order as well as for putting them back in order (in addition to using “resequencing” to mean putting them back in order). Plus, there is definitely a tendency in conversation for people (including me) to use “reordering” inconsistently.
I do see “misordering” used as well (RFC892, RFC3096, RFC4163, RFC9016, etc.) and agree that it would be less likely to be confusing, so perhaps that is a better term than “reordering”. I haven’t seen any confusion on the term “resequencing”. -Greg From: Joe Touch <[email protected]> Date: Monday, August 3, 2026 at 8:11 PM To: Greg White <[email protected]> Cc: Internet Area <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [IPsec] New Version Notification for draft-white-intarea-reordering-04.txt FWIW, IMO reordering and resquencing are synonymous. I would not expect readers to track the difference, even if coined as different in this document. I would encourage “misordering” as a more reliably interpreted term for changing the order of packets from their arrival. Also note: reordering and resequencing both could mean EITHER “putting things in the correct order” or “putting things back to the order in which they arrived” (which may not be correct). Delay is added whenever EITHER type of reordering/resequencing occurs - or (notably) when misordering occurs in the first place. Another type of delay that midpoint nodes should not try to correct is jitter, i.e., variation in the arrival of a packet stream. Again, any attempt to change the arrival pattern necessarily introduces delay - as does anything that increases that variation. I.e., the doc focuses on situations where the endpoint could allow packets to arrive out of order, but that’s not the only reason to avoid resequencing. Joe On Aug 3, 2026, at 4:51 PM, Greg White <[email protected]> wrote: Hi Joe, Thanks for the detailed feedback, this is very helpful. We will try to tackle as many of these suggestions as we can in the next version. For clarity, in the draft we defined the terms “reordering” = making packet out of order, “resequencing” = putting them back in order. To help avoid confusion, I’ve edited your points to align with this terminology - with square brackets where I’ve made a change. On your final point that it isn’t clear that this document is saying anything different from RFC3819: yes, the two excerpts you quoted aren’t markedly different, and Section 1 paragraph 2<https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html#section-1-2> indicates that the main issue with RFC3819 isn’t that statement, it is the text that follows. Also, I think we’ll end up with more concrete recommendations than what are in the draft currently. -Greg From: Joe Touch <[email protected]<mailto:[email protected]>> Date: Monday, August 3, 2026 at 8:42 AM To: Greg White <[email protected]<mailto:[email protected]>> Cc: Internet Area <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] New Version Notification for draft-white-intarea-reordering-04.txt Hi, all, Although the new and updated information provided in this document could be useful, it’s not clear that this document supersedes any of the advice provided in RFC 3819. Additionally, it omits key information as to why layer 2 frame ordering is maintained in certain protocols. In particular: - the abstract describes that [resequencing] “can introduce delays that result in net degradation of performance”. Those delays can also be irrelevant, e.g., if no further [resequencing] occurs and the receiver [resequences] anyway (as with TCP). The lack of such [resequencing] can also increase work at the receiver, as when TCP sends SACK rather than cumulative ACK. I.e., the impact is not always clear. - on-path interpretation of TCP streams, including DPI, don’t always react as well as modern TCP endpoints - the impact on fragmentation and reassembly is not addressed sufficiently; the discussion should cite the primary requirements (791, 8200) and go into a bit more detail. - IPsec is clearly sensitive to reordering. Most protocols, TCP included, can adapt to some level of reordering only up to a limit. Not only are there limits, but (as noted above) there is a cost at the receiver to support these capabilities. This doesn’t appear to be addressed. - there are MANY variations to TCP as deployed, as well as other protocols. Implementations with compromised resources, such as in IoT or low-power devices, may not all be up to “modern” standards. - there are protocols that require ordering at L2 (ATM being the primary example); it is useful to reiterate that this document isn’t recommending a change that would violate other L2 semantics that depend on ordering. AFAICT, the only clear requirements here are: Subnetwork implementers SHOULD avoid introducing unnecessary packet reordering. However, where packet reordering is an unavoidable consequence of mechanisms that improve overall performance or reliability (for example, packet striping across multiple links or link-layer retransmissions), the resulting packet reordering SHOULD generally be exposed to the receiving endpoint rather than hidden by subnetwork resequencing. RFC3819 says: This suggests that subnetwork implementers should try to avoid packet reordering whenever possible, but not if doing so compromises efficiency, impairs reliability, or increases average packet delay. It isn’t clear that this document is saying anything different from RFC3819. It may be useful as informational, but as presented it isn’t clear it should be a BCP; at best, it is an informative update to the context in which RFC3819 recommendations remain valid. Joe On Jul 7, 2026, at 9:19 AM, Greg White <[email protected]<mailto:[email protected]>> wrote: FYI On 7/6/26, 5:25 PM, "[email protected]<mailto:[email protected]> <mailto:[email protected]>" <[email protected]<mailto:[email protected]> <mailto:[email protected]>> wrote: A new version of Internet-Draft draft-white-intarea-reordering-04.txt has been successfully submitted by Greg White and posted to the IETF repository. Name: draft-white-intarea-reordering Revision: 04 Title: Proposal for Updates to Guidance on Packet Reordering Date: 2026-07-06 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.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-04.html <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html> HTMLized: https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering> Diff: https://author-tools.ietf.org/iddiff?url2=draft-white-intarea-reordering-04 <https://author-tools.ietf.org/iddiff?url2=draft-white-intarea-reordering-04> 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. To meet this requirement they implement a "resequencing" operation to restore the original packet order. This can introduce delays that result in net degradation of performance. Modern TCP and QUIC implementations support features that significantly improve their tolerance to out- of-order delivery. This draft is intended to provide new information for layer 2 technology standards regarding the need to assure in- order delivery to support IETF protocols. The IETF Secretariat _______________________________________________ IPsec mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ IPsec mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
