Re: [tsvwg] Robustness to packet reordering

[Bill Gage <[e-mail]>]

I think there is a bit of confusion about reordering by the 5G radio 
link protocol (RLP). The RLP encapsulates an IP packet inside an RLP 
protocol data unit (PDU) for transmission over the radio link between a 
wireless device (UE) and a base station. The RLP encompasses a number of 
functions including PDU segmentation and reassembly, PDU segment loss 
recovery (ARQ), RLP encryption and authentication, IP header compression 
(RoHC), and user data compression. Each PDU includes an RLP sequence 
number so that reassembled PDUs can be reordered for functions (like 
decompression) that require PDUs to be processed in a certain order. 
This reordering is transparent to the IP endpoints.

Once an IP packet has been successfully reconstructed by RLP, it becomes 
a candidate for forwarding to the destination IP endpoint. The RLP can 
be configured either to forward an IP packet as soon as it becomes 
available or to forward the IP packet in-order (according to the RLP 
sequence number). If in-order delivery is enabled, the RLP will buffer 
an out-of-order IP packet until either the missing packets become 
available or a re-ordering timer expires. Packet reordering is typically 
enabled for TCP sessions and disabled for UDP streams.

So, I think 5G RLP already has the necessary hooks to deal with 
reordering caused by radio link impairments and to cater to end-to-end 
needs of the application.

/bill

On 2025-02-12 3:30 a.m., Ingemar Johansson S wrote:

> I think a draft would be good. I can definitely help and add the 5G 
> specifics.
> There is a cost aspect with large reordering buffers in UEs (terminals) 
> and  network nodes for 5G as well and given that link throughput 
> increases so will also memory. But I think the main driver behind my 
> interest is to limit head of line blocking.
> Historically, reordering buffers in 5G (and before) has been to improve 
> TCP performance. Now that TCP and other protocols have potential to be 
> more robust against packet reordering then I think that it is time to 
> reconsider how things are done.
> 
> And with address to Sebasians and Joes discussion, yes, these are 
> relevant arguments and there is probably no “one shoe fits all”. I am 
> for instance not that keen to allow packets to go completely out of 
> sequence from 5G access as retransmissions on the MAC layer are quite 
> common, but that is perhaps more of concern for a number of transport 
> protocol stacks that do not work well when subject out of sequence 
> delivery.
> 
> There is concern about performance for RoHC, RoHC is to day mainly used 
> for VoLTE and VoNR which has its own data radio bearer. I see little 
> utility with RoHC otherwise.
>