On Thu, Feb 6, 2025, 11:00 AM Greg White <g.white= 40cablelabs....@dmarc.ietf.org> wrote:
> Cross-posting this topic to tsvwg. > > > On 2/6/25, 2:36 AM, "Ingemar Johansson S" <ingemar.s.johansson= > 40ericsson....@dmarc.ietf.org <mailto:40ericsson....@dmarc.ietf.org>> > 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 > > > > >
