Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
draft-ietf-tsvwg-l4s-arch-06
Transport Area Working Group B. Briscoe, Ed.
Internet-Draft Independent
Intended status: Informational K. De Schepper
Expires: September 10, 2020 Nokia Bell Labs
M. Bagnulo Braun
Universidad Carlos III de Madrid
G. White
CableLabs
March 9, 2020
Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture
draft-ietf-tsvwg-l4s-arch-06
Abstract
This document describes the L4S architecture, which enables Internet
applications to achieve Low 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. The L4S architecture is intended to enable
*all* Internet applications to transition away from congestion
control algorithms that cause queuing delay, to a new class of
congestion controls that utilize explicit congestion signaling
provided by the network. This new class of congestion control 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 both classes of congestion control to
coexist 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 never worse) than the
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 and to provide appropriate
congestion signaling to both types; protocol features that allow
network elements to identify L4S traffic and allow for communication
of congestion signaling; and host support for immediate congestion
signaling with an appropriate congestion response that enables
scalable performance.
Briscoe, et al. Expires September 10, 2020 [Page 1]
Internet-Draft L4S Architecture March 2020
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L4S Architecture Components . . . . . . . . . . . . . . . . . 8
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Why These Primary Components? . . . . . . . . . . . . . . 11
5.2. Why Not Alternative Approaches? . . . . . . . . . . . . . 13
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 17
Show full document text