All well put. There is also the congestion control issue with TCP, as well. I know there has been a lot of work in the area, but the classic congestion control will reduce the congestion window if it sees duplicate ACKs. On the sending end of a TCP connection, duplicate ACKs show up when there is packet loss. Out of order packet appear at first to be packet loss, because the first out of order packet can’t be discerned from a dropped packet).
How widely deployed are algorithms which don’t do congestion control based on packet loss? I should also point out that newer implementations of IPSec don’t have issues with packet re-ordering within a small window. That window was way too small on early systems, but new systems use a large window. From: Joe Touch <[email protected]> Sent: Monday, August 3, 2026 10:38 AM To: Greg White <[email protected]> Cc: Internet Area <[email protected]>; [email protected]; [email protected] Subject: [Int-area] Re: [IPsec] New Version Notification for draft-white-intarea-reordering-04.txt You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Penguin Solutions Security Checkpoint: External email. Please make sure you trust this source before clicking links or opening attachments. 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 reordering “can introduce delays that result in net degradation of performance”. Those delays can also be irrelevant, e.g., if no further reordering occurs and the receiver reorders anyway (as with TCP). The lack of such reordering 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]%20%3cmailto:[email protected]%3e>" <[email protected] <mailto:[email protected]<mailto:[email protected]%20%3cmailto:[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] To unsubscribe send an email to [email protected]
