Fragment reassembly is one reason. Another non-transport reason is IPsec
replay. But in both cases, it’s not just ordering that matters; it varies
depending on whether the stream is reordered in isolation or different
reordered streams are concurrent.
- in all cases, reordering matters within in a ’stream’, but the definition of
’stream’ varies
IPsec = IP addresses + SPI
IP reassembly = IP addresses + FragID
- out of order impact differs
IPsec =
reordering within a stream causes later packets of the same
stream to the dropped as replay attacks
interleaving of different reordered streams has no new impact
over interleaving of order-preserving streams
IPreassembly =
reordering within a stream set may or may not have any impact
over interleaving of order preserving streams
interleaving of different reordered streams consumes more
resources, as each pending stream requires a max-receive buffer
Otherwise, I can’t see a good reason either.
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
> On Mar 12, 2025, at 5:10 PM, Joel Halpern <[email protected]> wrote:
>
> 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, [email protected]
>>> <mailto:[email protected]> 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 <http://www.strayalpha.com/>
>>>
>>>> On Mar 11, 2025, at 1:05 PM, Greg White
>>>> <[email protected]>
>>>> <mailto:[email protected]> 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, "[email protected]
>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>> <mailto:[email protected]>" <[email protected]
>>>> <mailto:[email protected]> <mailto:[email protected]>
>>>> <mailto:[email protected]>> 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>
>>>> <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/>
>>>> <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>
>>>> <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>
>>>> <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 -- [email protected] <mailto:[email protected]>
>>>> To unsubscribe send an email to [email protected]
>>>> <mailto:[email protected]>
>>>
>>
>>
>> _______________________________________________
>> Int-area mailing list -- [email protected] <mailto:[email protected]>
>> To unsubscribe send an email to [email protected]
>> <mailto:[email protected]>
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
