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

Bob Briscoe <ietf@bobbriscoe.net> Mon, 13 June 2016 14:41 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEECA12D696 for <tcpprague@ietfa.amsl.com>; Mon, 13 Jun 2016 07:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7tw281GmH-J for <tcpprague@ietfa.amsl.com>; Mon, 13 Jun 2016 07:41:00 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14B212B051 for <tcpPrague@ietf.org>; Mon, 13 Jun 2016 07:40:59 -0700 (PDT)
Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:46553 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <ietf@bobbriscoe.net>) id 1bCT2v-0002W6-Rw; Mon, 13 Jun 2016 15:40:58 +0100
References: <20160613142347.12387.63962.idtracker@ietfa.amsl.com>
To: TCP Prague List <tcpPrague@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <575EC5F8.1090906@bobbriscoe.net>
Date: Mon, 13 Jun 2016 15:40:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160613142347.12387.63962.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------020607010305070700090208"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/mCcm0CDiZwnloAQkGlWgM3cgr0c>
Cc: Marcelo Bagnulo <marcelo@it.uc3m.es>, Koen De Schepper <koen.de_schepper@nokia.com>
Subject: [tcpPrague] New L4S Problem Statement: draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2016 14:41:03 -0000

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, internet-drafts@ietf.org 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/