[tcpPrague] L4S status update

Bob Briscoe <ietf@bobbriscoe.net> Tue, 01 November 2016 00:02 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 1E032129C03; Mon, 31 Oct 2016 17:02:16 -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 QO3M4aoyL5S1; Mon, 31 Oct 2016 17:02:13 -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 945ED129BFF; Mon, 31 Oct 2016 17:02:12 -0700 (PDT)
Received: from [77.40.224.170] (port=59439 helo=[10.0.102.204]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <ietf@bobbriscoe.net>) id 1c1MWp-0002qz-3x; Tue, 01 Nov 2016 00:02:11 +0000
To: tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>, AQM IETF list <aqm@ietf.org>, tcpm IETF list <tcpm@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net>
Date: Tue, 01 Nov 2016 00:02:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------8104AF989CDD82CEF66EA35D"
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/-5LOJuapCX-MVSu3rovr5DP7RRE>
Subject: [tcpPrague] L4S status update
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: Tue, 01 Nov 2016 00:02:16 -0000

tsvwg, aqm, tcpm, tcpPrague mailing lists,

A few people have been working away to specify and document all the 
aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) 
service, which held a successful BoF in Berlin. As the decision was to 
try to work across multiple WGs, I thought it would be useful to give ...

... the status collected over all activities and WGs. I've included 
stuff that has wider applicability but is also needed for L4S. Click on 
the headings to take you to the page where all these links are collected 
together.


    Source Code <https://riteproject.eu/dctth/#code>

  * Dual Queue Coupled AQM
      o With Curvy RED for Linux (access available shortly)
      o With PI2 for Linux <https://github.com/olgabo/dualpi2> [*UPDATED*]
  * Data Centre TCP (DCTCP) for
      o Linux (in the mainline kernel <https://www.kernel.org/>)
      o FreeBSD patch
        <http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037915.html>
      o ns2 patch <http://simula.stanford.edu/%7Ealizade/Site/DCTCP.html>.
  * Accurate ECN TCP Feedback for Linux
    <https://github.com/mirjak/linux-accecn/> [*COMPLETED*, but not
    fully tested]


    *IETF specs* <https://riteproject.eu/dctth/#ietf-specs>

As the architecture explains, there are three main parts to 
standardisation: the identifier (#1), the network algorithms (#2) and 
the host algorithms (#3):

  * Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
    Architecture and Problem Statement
    <draft-briscoe-tsvwg-l4s-arch
    <https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch>> [*NEW*]

 1. A proposed new identifier for Low Latency, Low Loss, Scalable
    throughput (L4S) packets
    <draft-briscoe-tsvwg-ecn-l4s-id
    <https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id>>
    [*UPDATED to reflect the proposed process*]
    and the IETF’s enabling draft to make way for this
    <draft-black-tsvwg-ecn-experimentation
    <https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-02.txthttps://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation>>
    [*NEW*]
 2. Then network operators can deploy a new simple active queue
    management algorithm, that complies with the few constraints
    specified here:
    <draft-briscoe-tsvwg-aqm-dualq-coupled
    <https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled>>
    Example algorithms are given in appendices. [*PI2 pseudocode added
    to make 2 example**appendices*]
 3. And host developers can deploy new scalable TCP algorithms, e.g.
    Data Centre TCP (DCTCP):
    <draft-ietf-tcpm-dctcp
    <https://tools.ietf.org/html/draft-ietf-tcpm-dctcp>>
    Without steps #2 & #3, scalable TCPs are too aggressive to coexist
    with classic TCPs like Reno and Cubic, so DCTCP was initially
    confined to controlled networks like Data Centres, where all classic
    traffic sources could be upgraded (or isolated). To be safe over the
    public Internet, scalable TCP algorithms will need to comply with
    the list of requirements agreed at an informally convened meeting in
    Prague that have become know as the TCP Prague requirements
    <https://mailarchive.ietf.org/arch/msg/tcpprague/mwWncQg3egPd15FItYWiEvRDrvA>:

  * One of these requirements is accurate ECN feedback, which the IETF
    has recognised will need an update to the TCP protocol, and it has
    stated the requirements a solution should comply with:
    <RFC7560 <http://tools.ietf.org/html/rfc7560>>
    A candidate protocol to satisfy these requirements has been
    developed and adopted by the IETF:
    <draft-ietf-tcpm-accurate-ecn
    <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn>> [*UPDATED*]
  * The following drafts address other specific TCP Prague requirements:
    Adding ECN to TCP control packets:
    <draft-bagnulo-tcpm-generalized-ecn
    <https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn>>
    [*UPDATED*]
    Recommendations for increasing TCP performance in low RTT networks:
    <draft-bagnulo-tcpm-tcp-low-rtt
    <https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt>>


    Papers <https://riteproject.eu/dctth/#papers>

  * Article in the IETF Journal describing the Demo in Bits-N-Bites at
    the IETF in Prague, July 2015.
    “Ultra-Low Delay for All
    <http://www.internetsociety.org/publications/ietf-journal-november-2015/ultra-low-delay-for-all>”
    IETF Journal, Nov 2015.
  * Description of an**ambitious demo of five low latency apps on one
    broadband line, 4 of which were also high throughput:
    “Ultra-Low Delay for All: Live Experience, Live Analysis
    <https://riteproject.files.wordpress.com/2015/10/uld4all-demo_mmsys.pdf>“,
    Proc. ACM Multimedia Systems; Demo Session (May 2016).
  * “/*PI^2 : A Linearized AQM for both Classic and Scalable TCP*/
    <https://riteproject.files.wordpress.com/2015/10/pi2_conext.pdf>,”
    Proc. ACM CONEXT 2016 (To appear Dec 2016). [*NEW*]


  *

    Finally, a pathetic apology is in order: We prepared a [*NEW*] paper
    for a top conference giving the full L4S story, with a massive set
    of testbed-based evaluations, with a wide range of link rates, RTTs,
    mixtures of numbers of flows in each queue, etc. etc.  But we
    screwed up, and it got rejected without even being read - we
    exceeded the page limit :(

    We don't want to publish it on the Web until we've tried again. But
    if anyone wants a private copy, pls just ask.
    Otherwise, the following older paper is still available, but not as
    comprehensive or well-honed:

    Pre-print of paper explaining why scalable TCP algorithms solve the
    problem (in plain English and maths), how the Dual Queue Coupled AQM
    algorithm works, and recording the results of extensive testbed
    experiments.
    “`/*Data Centre to the Home’: Ultra-Low Latency for All*/
    <http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf>” (2015)


Thank you to everyone involved so far.

Cheers


Bob

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