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

Derek Fawcus <dfawcus+lists-tsvwg@employees.org> Thu, 15 July 2021 21:36 UTC

Return-Path: <dfawcus@employees.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E643A106D for <tsvwg@ietfa.amsl.com>; Thu, 15 Jul 2021 14:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_p7U9CHssBH for <tsvwg@ietfa.amsl.com>; Thu, 15 Jul 2021 14:36:21 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483B93A106A for <tsvwg@ietf.org>; Thu, 15 Jul 2021 14:36:21 -0700 (PDT)
Received: by clarinet.employees.org (Postfix, from userid 1736) id A640A4E11B15; Thu, 15 Jul 2021 21:36:18 +0000 (UTC)
Date: Thu, 15 Jul 2021 22:36:18 +0100
From: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>
To: tsvwg@ietf.org
Message-ID: <YPCqUsgCaKdcfmPr@clarinet.employees.org>
References: <162514219180.12127.896362279994031453@ietfa.amsl.com> <30f835be-9348-168d-3fdc-539725199bd9@bobbriscoe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <30f835be-9348-168d-3fdc-539725199bd9@bobbriscoe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/W32eWTvIN4Sdz9be02nuR_xP968>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-18.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2021 21:36:27 -0000

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.