Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-18.txt

[Bob Briscoe <[e-mail]>]

Derek,

Thanks for looking into this. I can see the tension between the e2e 
principle and 'intelligence' in the network here. For instance, 
resequencing over SRNS relocation will just deliver stuff late that 
applications will have to sort out themselves anyway. Whatever, the 
world is what it is...

We can point out in the draft that, if an operator is going to schedule 
different subsets of a traffic aggregate within a tunnel separately, 
they need to take care not to enable resequencing at the egress. But, 
I'm reticent to do it, 'cos it's sort of rather patronizing to tell 
people not to do something so daft. No-one's going to deploy L4S without 
testing, so if someone does do something daft, they will find out well 
in advance.

Anyway, in the case of L4S, 3GPP discussions are heading towards putting 
L4S and Classic under different 5QIs (5G QoS Identifiers). In which case 
they won't be sequenced together anyway.

But, if people in the WG think this is important, it's easy to add a new 
little section giving this advice.

Cheers


Bob

On 15/07/2021 22:36, Derek Fawcus wrote:
> On Thu, Jul 01, 2021 at 01:45:05PM +0100, Bob Briscoe wrote:
>> Non-changes:
>>
>>    * After consulting with the int-area
>>      <https://mailarchive.ietf.org/arch/msg/int-area/y5UmhfSAka7xi_iBvX50bZ0jxzQ/>
>>      and PALS
>>      <https://mailarchive.ietf.org/arch/msg/pals/iWxEpj0MB-Du_U8KjelIocbg6Yk/>
>>      lists (follow the links for the relevant long threads), it was
>>      decided there is no need to mention that tunnels that support
>>      resequencing like L2TP should have it disabled for data channels
>>      carrying L4S traffic (because there's no evidence that any would
>>      enable sequencing for IP data - sequencing is generally for the
>>      tunnel control channel or for stateful header compression that
>>      nowadays hinders rather than helps performance).
> BTW - GTP-U (a tunnel over UDP) also has an (optional) sequence number
> and I believe it can carry IP traffic - being as it is for 3GPP.
>
> Now as to when that data has to be in a preserved sequence, and how
> often that sequence number will be used, I do not know.  The quoted
> text below suggests one use case.
>
> Certainly section 9.1.1 of 3GPP TS 29.060, rev h00 mentions it use,
> specifically for ensuring in order deliver when required.
>
>    (https://www.3gpp.org/ftp/Specs/archive/29_series/29.060/29060-h00.zip)
>
> DF
>
>      9.1.1	Handling of Sequence Numbers
>      
>      This functionality is provided only when the S bit is set to 1 in the GTP-U header.
>      
>      The GTP-U protocol entity must reorder out of sequence T-PDUs when in sequence delivery is required. This is optional at the SGSN in UMTS. The GTP-U protocol entity shall deliver to the user plane entity only in sequence TPDUs and notify the sequence number associated to each of them. The notification of the sequence number is not necessary at the GGSN, but it is mandatory at the SGSN and RNC. The user plane entity shall provide a sequence number to the GTP-U layer together with T-PDUs to be transmitted in sequence. GTP-U protocol entities at the GGSN may optionally generate autonomously the sequence number, but should be able to use sequence numbers provided by the user plane entity. The sequence number is handled on a per GTP-U Tunnel (that is TEID) basis.
>      
>      When the sequence number is included in the GTP-U header, a user plane entity acting as a relay of T-PDUs between GTP-U protocol entities, or between PDCP (or SNDCP) protocol entities and GTP-U protocol entities, shall relay the sequence numbers between those entities as well. In this way it is possible to keep consistent values of sequence numbers from the GGSN to the UE (MS in GPRS) by relaying the sequence number across the CN GTP-U bearer, the Iu GTP-U bearer and the Radio bearer (via PDCP or SNDCP N-PDU numbers). This functionality is beneficial during SRNS relocation.
>      
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/