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]
