Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
draft-briscoe-tsvwg-l4s-arch-02
| Document | Type | Replaced Internet-Draft (tsvwg WG) | |
|---|---|---|---|
| Authors | Bob Briscoe , Koen De Schepper , Marcelo Bagnulo | ||
| Last updated | 2017-04-09 (Latest revision 2017-03-30) | ||
| Replaces | draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem | ||
| Replaced by | draft-ietf-tsvwg-l4s-arch | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
|
||
| Stream | WG state | Adopted by a WG | |
| Document shepherd | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-tsvwg-l4s-arch | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document describes the L4S architecture for the provision of a new service that the Internet could provide to 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
Koen De Schepper
Marcelo Bagnulo
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)