[tsvwg] I-D Action: draft-ietf-tsvwg-l4s-arch-05.txt

internet-drafts@ietf.org Thu, 20 February 2020 13:59 UTC

Return-Path: <internet-drafts@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9B120878; Thu, 20 Feb 2020 05:59:00 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tsvwg@ietf.org
Message-ID: <158220714067.12468.13028488098433690796@ietfa.amsl.com>
Date: Thu, 20 Feb 2020 05:59:00 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4iDkRdE1B63h774RNN61ZsxbCLQ>
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-l4s-arch-05.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Feb 2020 13:59:07 -0000

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           : Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
        Authors         : Bob Briscoe
                          Koen De Schepper
                          Marcelo Bagnulo
                          Greg White
	Filename        : draft-ietf-tsvwg-l4s-arch-05.txt
	Pages           : 36
	Date            : 2020-02-20

Abstract:
   This document describes the L4S architecture, which enables Internet
   applications to achieve Low Latency, Low Loss, and Scalable
   throughput (L4S), while coexisting on shared network bottlenecks with
   existing Internet applications that are not built to take advantage
   of this new technology.

   In traditional bottleneck links that utilize a single, shared egress
   queue, a variety of application traffic flows can share the
   bottleneck queue simultaneously.  As a result, each sender's behavior
   and its response to the congestion signals (delay, packet drop, ECN
   marking) provided by the queue can impact the performance of all
   other applications that share the link.  Furthermore, it is
   considered important that new protocols coexist in a reasonably fair
   manner with existing protocols (most notably TCP and QUIC).  As a
   result, senders tend to normalize on behaviors that are not
   significantly different than those in use by the majority of the
   existing senders.  For many years, the majority of traffic on the
   Internet has used either the Reno AIMD congestion controller or the
   Cubic algorithm, and as a result any newly proposed congestion
   controller needs to demonstrate that it provides reasonable fairness
   when sharing a bottleneck with flows that use Reno or Cubic.  This
   has led to an ossification in congestion control, where improved
   congestion controllers cannot easily be deployed on the Internet.

   It is well known that the common existing congestion controllers
   (e.g.  Reno and Cubic) increase their congestion window (the amount
   of data in flight) until they induce congestion, and they respond to
   the congestion signals of packet loss (or equivalently ECN marks) by
   significantly reducing their congestion window.  This leads to a
   large sawtooth of the congestion window that manifests itself as a
   combination of queue delay and/or link underutilization.

   Meanwhile, in closed network environments, such as data centres, new
   congestion controllers (e.g.  DCTCP [RFC8257]) have been deployed
   that significantly outperform Reno and Cubic in terms of queue delay
   and link utilization across a much wider range of network conditions.

   The L4S architecture provides an approach that allows for the
   deployment of next generation congestion controllers while preserving
   reasonably fair coexistence with Reno and Cubic.

   The L4S architecture consists of three components: network support to
   isolate L4S traffic from other 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 and an appropriate congestion response that enables
   scalable performance.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-05
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-05

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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