Also note L4S: Low Latency Low Loss Scalable throughput, copied below, which uses AQM technology to reduce latency.
=================
L4S
- Name: L4S (Low Latency Low Loss Scalable throughput)
- Description: L4S is a new service that the Internet could
provide to eventually replace best efforts for all traffic: Low queuing
Latency, Low congestion Loss, Scalable throughput (L4S). In extensive
testing, L4S has been demonstrated to keep average queuing delay under a
millisecond for all applications, even when together they add
up to a heavy load (unlike Diffserv which merely gives low latency to
some packets at the expense of others). At the same time L4S keeps
congestion loss to zero and gives full utilization. Even with a high
capacity broadband access, the resulting performance under load is
remarkably and consistently improved 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).
L4S is designed so that it is so much better than the existing service that network operators will want to deploy it, and so that they can
deploy it incrementally alongside the existing best efforts service.
Then all of a user's applications can shift to it when they update their
stack. Access networks are typically designed with one link as the
bottleneck for each "site" (which might be a home, small business,
enterprise or mobile device). So deployment at one (or both) ends of the
bottleneck link to a "site" should give nearly all the benefit. L4S is a
zero-config solution based on active queue management (AQM) technology.
The queue management code is very simple and it requires no packet
inspection deeper than the IP layer.
The host part of L4S is based on the congestion control used in Data
Centre TCP (DCTCP). This finally solves the long-recognized problem that
TCP has had with throughput scalability. Previous variants such as TCP
Cubic are good, but they are ultimately only partially-scalable
stop-gaps. Work is also ongoing to modify the congestion controls in
transports other than TCP to support L4S. L4S is not only applicable to
the public Internet; it would also extend the applicability of DCTCP to
multi-tenant cloud data centres and interconnection between Data
Centres.
- Agenda
- (10mins) Problem Statement (Bob Briscoe)
- Activity/ Interest/ Use Cases/ Plans:
- (15mins) L4S e2e broadband testbed, demonstrator and plans (Koen De Schepper)
- (10mins) L4S Applicability to Mobile - without flow inspection (Kevin Smith)
- (10mins) L4S for 4G/5G + involving 3GPP (Ingemar Johansson)
- ( 5mins) DCTCP and its Evolution (Praveen Balasubramanian)
- (10mins) Clarification Questions (Chairs)
- (10mins) Deliverables (Marcelo Bagnulo Braun)
- (30mins) Discussion (Chairs)
- (10mins) Polls (Chairs)
- (10mins) Slippage (All!)
- Status: Expected to be Non-WG Forming (but discussion with ADs ongoing). Intended to work across existing WGs.
- Responsible AD: Mirja Kuelewind
- BoF proponents: Bob Briscoe <ietf@xxxxxxxxxxxxxx>, Koen De Schepper <koen.de_schepper@xxxxxxxxx>
- BoF chairs: Phil Eardley willing.
- Number of people expected to attend: 200
- Length of session: 2 hours
- Conflicts to avoid: all Transport Area WGs, avtcore, iccrg
- Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.
- Mailing List: https://www.ietf.org/mailman/listinfo/tcpprague
- Draft charter: N/A (but see Deliverables link above)
- Relevant drafts:
- L4S Problem Statement:
- L4S Identifier
- Dual Queue Coupled AQM
- Relevant Drafts already adopted:
- Supporting Materials (videos of demos, papers, presentations, source code, etc):
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.