[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/
- [tcpPrague] L4S status update Bob Briscoe
- Re: [tcpPrague] L4S status update hiren panchasara
- Re: [tcpPrague] [aqm] L4S status update Bless, Roland (TM)
- Re: [tcpPrague] [aqm] L4S status update Ingemar Johansson S
- Re: [tcpPrague] [aqm] L4S status update Bless, Roland (TM)
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update Jonathan Morton
- Re: [tcpPrague] [aqm] L4S status update Mario Hock
- Re: [tcpPrague] [aqm] L4S status update Bless, Roland (TM)
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update De Schepper, Koen (Nokia - BE)
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update Bob Briscoe
- Re: [tcpPrague] [aqm] L4S status update Jonathan Morton
- Re: [tcpPrague] [aqm] L4S status update Matt Mathis
- Re: [tcpPrague] [aqm] L4S status update Jonathan Morton
- Re: [tcpPrague] [aqm] L4S status update Dave Täht
- Re: [tcpPrague] [aqm] L4S status update Dave Täht
- Re: [tcpPrague] [aqm] L4S status update Dave Täht
- Re: [tcpPrague] [tcpm] [aqm] L4S status update John Leslie
- Re: [tcpPrague] [tcpm] [aqm] L4S status update Jonathan Morton