Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
draft-ietf-tsvwg-l4s-arch-02

Document Type Expired Internet-Draft (tsvwg WG)
Last updated 2018-09-23 (latest revision 2018-03-22)
Replaces draft-briscoe-tsvwg-l4s-arch
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state WG Document (wg milestone: Sep 2018 - Submit "Low Latency,... )
Document shepherd Wesley Eddy
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to Wesley Eddy <wes@mti-systems.com>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4s-arch-02.txt

Abstract

This document describes the L4S architecture for the provision of a new Internet service that could eventually replace best efforts for all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is becoming common for _all_ (or most) applications being run by a user at any one time to require low latency. However, the only solution the IETF can offer for ultra-low queuing delay is Diffserv, which only favours a minority of packets at the expense of others. In extensive testing the new L4S service keeps average queuing delay under a millisecond for _all_ applications even under very heavy load, without sacrificing utilization; and it keeps congestion loss to zero. It is becoming widely recognized that adding more access capacity gives diminishing returns, because latency is becoming the critical problem. Even with a high capacity broadband access, the reduced latency of L4S remarkably and consistently improves performance under load for applications such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps (even when all being used at once over the same access link). The insight is that the root cause of queuing delay is in TCP, not in the queue. By fixing the sending TCP (and other transports) queuing latency becomes so much better than today that operators will want to deploy the network part of L4S to enable new products and services. Further, the network part is simple to deploy - incrementally with zero-config. Both parts, sender and network, ensure coexistence with other legacy traffic. At the same time L4S solves the long-recognized problem with the future scalability of TCP throughput. This document describes the L4S architecture, briefly describing the different components and how the work together to provide the aforementioned enhanced Internet service.

Authors

Bob Briscoe (ietf@bobbriscoe.net)
Koen Schepper (koen.de_schepper@nokia.com)
Marcelo Bagnulo (marcelo@it.uc3m.es)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)