Subject: [tcpPrague] New L4S Problem Statement: draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jun 2016 15:40:56 +0100

Folks,

We've just submitted a new version of our problem statement for L4S.

We'd be particularly interested to hear from anyone who has a use-case - 
either one that isn't mentioned already, or where they think one that is 
mentioned could be written better/differently.
If they would like to describe your use-case in a couple of sentences, 
we could add it.

*Diffs**
*You can get all the diffs via the links at the top of 
https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
The main diffs are:
* Abstract: Completely new (previous one talked about L4S service as if 
the network alone provided it, without mentioning the key role of the 
hosts);
* Quantification: of the problem and  quantified claims about example 
solutions
* Added ASCII art architecture, and made numbering of parts, and of 
proposed deliverables consistent
* Added more definitions of terminology
* Completed sections that were previously only bulletted:
   - 2 Rationale
     2.1 Why These Primary Components?
     2.2 Why Not Alternative Approaches?
   - 3.1 Use-Cases
   - 5.3 ECN Integrity
* Explained tables of deliverables in appendix

Bob

On 13/06/16 15:23, [email-masked] wrote:
> A new version of I-D, draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Name:		draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem
> Revision:	01
> Title:		Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Problem Statement
> Document date:	2016-06-10
> Group:		Individual Submission
> Pages:		23
> URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem/
> Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
>
> Abstract:
>     This document motivates 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 explains the underlying problems that have been
>     preventing the Internet from enjoying such performance improvements.
>     It then outlines the parts necessary for a solution and the steps
>     that will be needed to standardize them.  It points out opportunities
>     that will open up, and sets out some likely use-cases, including
>     ultra-low latency interaction with cloud processing over the public
>     Internet.
>
>                                                                                    
>
>
> 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.
>
> The IETF Secretariat
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/