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]> Date: Monday, August 3, 2026 at 8:42 AM 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 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]> wrote: FYI On 7/6/26, 5:25 PM, "[email protected] <mailto:[email protected]>" <[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] To unsubscribe send an email to [email protected]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
