See Rfc3819, sec 15
—Joe Touch, temporal epistemologist Cross-posting this topic to tsvwg.On 2/6/25, 2:36 AM, "Ingemar Johansson S" <[email protected] <mailto:[email protected]>> 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.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
|
