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

From: [email-masked]
Date: Thu, 01 Jul 2021 05:23:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)
        Authors         : Koen De Schepper
                          Bob Briscoe
	Filename        : draft-ietf-tsvwg-ecn-l4s-id-18.txt
	Pages           : 57
	Date            : 2021-07-01

Abstract:
   This specification defines the protocol to be used for a new network
   service called low latency, low loss and scalable throughput (L4S).
   L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
   layer that is similar to the original (or 'Classic') ECN approach,
   except as specified within.  L4S uses 'scalable' congestion control,
   which induces much more frequent control signals from the network and
   it responds to them with much more fine-grained adjustments, so that
   very low (typically sub-millisecond on average) and consistently low
   queuing delay becomes possible for L4S traffic without compromising
   link utilization.  Thus even capacity-seeking (TCP-like) traffic can
   have high bandwidth and very low delay at the same time, even during
   periods of high traffic load.

   The L4S identifier defined in this document distinguishes L4S from
   'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
   migration path so that suitably modified network bottlenecks can
   distinguish and isolate existing traffic that still follows the
   Classic behaviour, to prevent it degrading the low queuing delay and
   low loss of L4S traffic.  This specification defines the rules that
   L4S transports and network elements need to follow with the intention
   that L4S flows neither harm each other's performance nor that of
   Classic traffic.  Examples of new active queue management (AQM)
   marking algorithms and examples of new transports (whether TCP-like
   or real-time) are specified separately.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-18

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 1 Jul 2021 13:45:05 +0100

tsvwg,

The latest rev of the l4s architecture draft announced below was updated 
as follows:

The anti-replay problem: Focusing on VPN configuration solutions, rather 
than changes to VPN implementations, which are out of scope for L4S. 
These are in 3 places:

  * §6.2 "VPN Behaviour to Avoid Limitations of Anti-Replay"
  * §9 "Security Considerations"
  * Appendix B.  "Compromises in the Choice of L4S Identifier"

Also:

  * Changes to the terminology section, to remain consistent with
    l4s-arch (new rev also just posted)
  * Putting the citation of RFC4774 in context.
  * Misc other changes we noticed during editing.

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).

Please check the changes and let the list know if there are new problems.

Cheers

Bob

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

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 15 Jul 2021 22:36:18 +0100

>     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.

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 15 Jul 2021 22:57:55 +0100

>     nowadays hinders rather than helps performance).

While that was the service provider view, it is not the only deployment
of L2TP.  So I'm not sure that this is a safe assumption, as one of the
cases I believe I mentioned in that thread is the Microsoft RAS VPN product.

It has at least two forms, PPTP (IP/PPP/GREv1) and L2TP/IPsec (IP/PPP/L2TP/ESP).
Both forms can make use of sequence numbers in their encapsulation.

I know the PPTP version is still actively being used, as we recently ended
up adding an ALG for it to our CGNAT software, due to requests.

We used to support use of the L2TP form in our product around 3 years ago,
so it was still in use then.  It could well still be in use, as it often
'just works' through NATs since its ESP has a version of UDP NAT-Traversal.

Last I played with these, the MS version offered the ability to enable
compression, which I believe included IP header compressions, and so may
be reordering sensitive.

The problem here would be in determining the degree of use, and if people
(usually not being specialists) have enabled compression.  Certainly one
place I worked at some years ago had enabled compression, that was by
someone who just viewed compression as good.  This was a SME, which seems
to be the usual use case.

DF

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 26 Jul 2021 20:46:11 +0100

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 26 Jul 2021 20:59:23 +0100

Derek,

Thanks again for digging into this. I'm beginning to realize this sort 
of thing is not really for the current drafts, which are focused on 
implementation requirements. Configuring sequencing is more advice for 
running the L4S experiment. I have seen offlist discussions about 
starting such a draft (l4sops scope is purely about the coexistence 
issue, so not an appropriate place). So if advice about sequencing goes 
anywhere, it ought to go in an ops guidance draft about running L4S 
experiments.

Like you say, the question is determining the degree of use. If the odd 
(misguided?) user is going to turn on compression in their VPN, and then 
possibly need sequencing (depending on what type of compression they are 
using), they won't get the benefit of low delay while some of their 
traffic is Classic, because the sequencing will hold back the L4S until 
the Classic catches up. That's their choice, and I doubt they are going 
to benefit from the RFCs advising them not to screw up.

Again, we can add such advice if the WG wants. But I'd like to see more 
pressure to do so before we complicate any of the L4S drafts even further.

Bob