Re: [tsvwg] Re: Robustness to packet reordering

[Tom Herbert <[e-mail]>]

On Thu, Feb 6, 2025, 11:00 AM Greg White <g.white=
[e-mail]> wrote:

> Cross-posting this topic to tsvwg.
>
> > On 2/6/25, 2:36 AM, "Ingemar Johansson S" <ingemar.s.johansson=
> [e-mail] <mailto:[e-mail]>>
> wrote:
> > [snip]
> > The reason I ask is that we poll the interest in the support for out of
> order delivery of packets in 5G. The outline is that we ensure in order
> delivery for
> > up to some given milliseconds, to handle possible HARQ retransmissions
> on the MAC layer. Beyond that we forward packets as they are processed by
> > the radio stack.
> > The rationale behind this is to avoid that packets for latency sensitive
> flows (streams) are delayed more than necessary if they share the same data
> > radio bearer as other streams.
> > [snip]
>
> This is an important topic relating to the expectations and requirements
> that transport protocols place on layer 2 protocols.  In layer 2 standards
> bodies that I've been involved in, it has been understood that "the upper
> layers" expect in-order delivery, and since the L2 protocols commonly don't
> have visibility or awareness of L4+ sessions (connections, streams, etc.)
> they are often designed to handle L2 retransmissions (or other sources of
> re-ordering in L2) by delaying all frames in the L2 link - to the detriment
> of all latency-sensitive L4+ sessions that might be sharing that L2 link.
>  A few years ago, I recall there was a brief discussion in TSVWG (or
> possibly TSVAREA) about this, and would it be possible to change this
> requirement on L2.  Unfortunately, I don't think any action came from that
> discussion at the time.
>

Greg,

>
There's no requirement for in order delivery, that's fundamental to IP.
There are some L4 protocols that operate better with in order delivery,
like TCP. Selective Acknowledgements mitigate issues with OOO to a large
extent.

There is also a trend in data centers towards packet spaying across
networks. That is each packet in a flow can take a different path to the
destination so that OOO is common. Newer transports can take this into
account (lots of SACKs, conveying packets packed via bitmaps).

Tom


> In my opinion, this is a topic that could use some further discussion.
> It's unclear to me how this requirement has been communicated to layer 2
> standards bodies, so it is similarly unclear to me how the IETF would
> communicate any change to it. Assuming there is a reasonable answer to
> that, what would be a better requirement for the IETF provide to layer 2?
>
> I assume there are some L4 implementations (and tunneling protocols) that
> are reordering sensitive today, so perhaps this isn't an easy thing to
> change, but it would be good to understand the scale of deployment of such
> protocols. In the NQB draft
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-27.html#section-4.5
> we have a section that mentions reordering sensitive tunneling protocols.
> It references RFC 2983 which describes certain (possibly optional) features
> of IPSEC and L2TP which create some ordering sensitivity. In addition, I
> recall some discussion about replay-attack safeguards in some encrypted
> tunneling protocols that might have problems with reordering.  Obviously,
> older TCP implementations that don't support RACK would have problems with
> reordering.
>
> I would be interested if you could share any aspects of the discussion in
> 5G on this topic.
>
> -Greg
>
>
>
>
>