I am trying to think why IP (as distinct from TCP / QUIC / ..) would
care about ordering at all. I suppose the corner case of reordered
fragments could be considered relevant to IP. But mostly, this seems to
belong at transport, not IP.
Yours,
Joel
PS: I think the wording in the draft could be clearer that this is data
for input to L2 standards bodies, not recommendations for behavior at L2.
On 3/12/2025 8:02 PM, Greg White wrote:
Thanks Joe.
Yes, that could be case, but IMO it would be out of scope for the
draft to explore non-IP use cases.
Perhaps the goal of this document could be described as gathering the
current wisdom around the implications, positive and negative, of L2
resequencing on IP.
Greg
On Mar 12, 2025, at 5:32 PM, to...@strayalpha.com wrote:
Hi Greg,
FWIW, it might be useful to note that some L2s maintain ordering for
their own purposes, e.g., ATM did so to simplify fragmentation and
reassembly in its own protocol layers. Others may rely on in-order
delivery for control messages (do Ethernet BPDUs require this?).
I.e., it’s not always something L2 does for IP…
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
On Mar 11, 2025, at 1:05 PM, Greg White
<g.white=40cablelabs....@dmarc.ietf.org> wrote:
Hi all,
There was a recent discussion on the QUIC and TSVWG mailing lists*
regarding the somewhat common implementation in L2 networks of
guaranteeing in-order delivery by delaying higher-sequenced L2
frames while waiting for a later arriving lower-sequenced frame.
This practice has been important historically, but brings multiple
costs due to implementation complexity and L2 protocol complexity.
In addition, the re-sequencing may end up doing more harm than good,
since it is generally done without knowledge of the higher-layer
protocol contexts (e.g. the late packet that triggers the delay
might be for a different TCP connection than the ones that get
delayed). Since modern TCPs and many QUIC implementations are
tolerant of some reordering, a few of us thought it would be
worthwhile to have a broader discussion and see if we could agree on
new guidance that the IETF could provide to L2 standards orgs.
Intarea was suggested as being the most appropriate WG to bring the
discussion to.
To that end, we've written a draft. The datatracker version
(draft-00) is linked below, but the version on GitHub is more
up-to-date.
https://gwhitecl.github.io/draft-white-intarea-reordering/draft-white-intarea-reordering.html
There is a short slot on the agenda on Monday to introduce the draft
and get reactions.
Best regards,
Greg
*
https://mailarchive.ietf.org/arch/browse/tsvwg/?gbt=1&q=%22Robustness%20to%20packet%20reordering%22
On 3/3/25, 3:56 PM, "internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>" <internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>> wrote:
A new version of Internet-Draft
draft-white-intarea-reordering-00.txt has been
successfully submitted by Greg White and posted to the
IETF repository.
Name: draft-white-intarea-reordering
Revision: 00
Title: Proposal for Updates to Guidance on Packet Reordering
Date: 2025-03-03
Group: Individual Submission
Pages: 6
URL:
https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.txt
<https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.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-00.html
<https://www.ietf.org/archive/id/draft-white-intarea-reordering-00.html>
HTMLized:
https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering
<https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering>
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. In addition, certain
link types can introduce out-of-order arrivals at the end of the
layer 2 link, which the receiving equipment is required to rectify by
delaying higher sequenced frames until all lower sequenced frames can
be delivered or are deemed lost. The delaying of higher sequenced
frames is generally done without any knowledge of the higher layer
protocols in use, let alone any knowledge of higher layer protocol
contexts (e.g. TCP connections) in the case that the layer 2 link is
carrying a multiplex of such contexts. It could, for example, be the
case that all of the higher sequenced frames being delayed are
carrying packets for different layer 4 contexts than a single lower-
sequenced frame that triggered the delay. The result is that this
"re-sequencing" operation can introduce delays that result in
degradation of performance rather than improving it. Moreover,
modern, performant TCP and QUIC implementations support features that
significantly improve their tolerance to out-of-order delivery.
This draft is intended to promote an analysis and discussion of the
sensitivity of modern protocols to out-of-order delivery, and to
potentially develop new guidance to layer 2 technology standards
regarding the need to assure in-order delivery.
The IETF Secretariat
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
_______________________________________________
Int-area mailing list --int-area@ietf.org
To unsubscribe send an email toint-area-le...@ietf.org
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
