> On 3. Aug 2026, at 17:43, Robinson, Herbie > <[email protected]> wrote: > > 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? Are you really interested in this or are you actually interested loss detection algorithms which tolerate some level of reordering? Here RACK (RFC 8985) comes into my mind.
Best regards Michael > 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]. Learn why this is > important > 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]> 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]
