The IESG has approved the following document: - 'Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture' (draft-ietf-tsvwg-l4s-arch-20.txt) as Informational RFC
This document is the product of the Transport Area Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/ Technical Summary This document describes the L4S architecture, which enables Internet applications to achieve Low queuing Latency, Low Loss, and Scalable throughput (L4S). The insight on which L4S is based is that the root cause of queuing delay is in the congestion controllers of senders, not in the queue itself. With the L4S architecture all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay, to a new class of congestion controls that induce very little queuing, aided by explicit congestion signalling from the network. This new class of congestion controls can provide low latency for capacity-seeking flows, so applications can achieve both high bandwidth and low latency. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. These mechanisms aim to ensure that the latency and throughput performance using an L4S-compliant congestion controller is usually much better (and rarely worse) than performance would have been using a 'Classic' congestion controller, and that competing flows continuing to use 'Classic' controllers are typically not impacted by the presence of L4S. These characteristics are important to encourage adoption of L4S congestion control algorithms and L4S compliant network elements. The L4S architecture consists of three components: network support to isolate L4S traffic from classic traffic; protocol features that allow network elements to identify L4S traffic; and host support for L4S congestion controls. The protocol is defined separately as an experimental change to Explicit Congestion Notification (ECN). Working Group Summary The working group largely supports and is enthusiastic about L4S technology, which this document is a part of. It was last called along with 2 other L4S documents. There is a wider than normal level of support that has been expressed for this work, but it is not unanimous. There are also some WG participants who have concerns about L4S or prefer an alternative approach. The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety. Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with. Document Quality There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology. Personnel The Shepherd is Wes Eddy. The AD is Martin Duke. _______________________________________________ IETF-Announce mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-announce
