From nobody Tue Mar 9 05:43:22 2021 Return-Path: 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 11FBC3A0C46; Tue, 9 Mar 2021 05:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 VA72fEkgEgez; Tue, 9 Mar 2021 05:43:09 -0800 (PST) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 59D9C3A0C38; Tue, 9 Mar 2021 05:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:To:References:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+RDw6UXY+ugL8JuVTemIMxM7tTH032wFFA/95h6Tjm4=; b=8BniuHZka/S4u68bDC7spL3w7 fLBxtm/fUJlx7wCkmRzITBSgWINsTajDYPpom3kGvYqCvf+fe+H6GkfgUW9Dnt4Fzt8AHosv/4mpy 4PZycsZ6RP8MIwAY6A2/sHe2n607HwMQ/0+zcJhtbqaiOieoihF9pCvI1DKgTdUPtP9B7MN0oMbHf E5eJ7sriFSvOkjVCE7RAM+yZNaGSGTpxrpSJ4uYAnXDN3rQ1nmJHF30VYGvo+G1ozNigag0hCzoux bkynWK+F8peQL9qbXpL0fxqf+uYtRbLaCtriudG9C34rOfCUHpaelOg7bPPeJdFlHjXVhL1+LdhQg SBuG9Vk+g==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:44262 helo=[192.168.1.9]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lJcdb-0003OJ-IS; Tue, 09 Mar 2021 13:43:04 +0000 References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> To: tsvwg IETF list , iccrg IRTF list , TCP Prague List , tcpm IETF list From: Bob Briscoe X-Forwarded-Message-Id: <161529694562.32408.1003733576456029769@ietfa.amsl.com> Message-ID: <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> Date: Tue, 9 Mar 2021 13:42:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <161529694562.32408.1003733576456029769@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D2E9325EBF00860BD35C868F" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [tcpPrague] New draft: draft-briscoe-iccrg-prague-congestion-control-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.29 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 13:43:12 -0000 This is a multi-part message in MIME format. --------------D2E9325EBF00860BD35C868F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit iccrg, tsvwg, tcpm, tcpPrague lists, We've just posted the first draft that documents the Prague Congestion Control. Abstract and links below. It's been promised (and actually the core section was 90% written) for a while now. Finally finished the whole thing. Hope it helps. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-briscoe-iccrg-prague-congestion-control-00.txt Date: Tue, 09 Mar 2021 05:35:45 -0800 From: internet-drafts@ietf.org To: Bob Briscoe , Koen De Schepper , Olivier Tilmans A new version of I-D, draft-briscoe-iccrg-prague-congestion-control-00.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-briscoe-iccrg-prague-congestion-control Revision: 00 Title: Prague Congestion Control Document date: 2021-03-09 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-control-00.txt Status: https://datatracker.ietf.org/doc/draft-briscoe-iccrg-prague-congestion-control/ Htmlized: https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control Htmlized: https://tools.ietf.org/html/draft-briscoe-iccrg-prague-congestion-control-00 Abstract: This specification defines the Prague congestion control scheme, which is derived from DCTCP and adapted for Internet traffic by implementing the Prague L4S requirements. Over paths with L4S support at the bottleneck, it adapts the DCTCP mechanisms to achieve consistently low latency and full throughput. It is defined independently of any particular transport protocol or operating system, but notes are added that highlight issues specific to certain transports and OSs. It is mainly based on the current default options of the reference Linux implementation of TCP Prague, but it includes experience from other implementations where available. It separately describes non-default and optional parts, as well as future plans. The implementation does not satisfy all the Prague requirements (yet) and the IETF might decide that certain requirements need to be relaxed as an outcome of the process of trying to satisfy them all. In two cases, research code is replaced by placeholders until full evaluation is complete. 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 --------------D2E9325EBF00860BD35C868F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit iccrg, tsvwg, tcpm, tcpPrague lists,

We've just posted the first draft that documents the Prague Congestion Control.
Abstract and links below.

It's been promised (and actually the core section was 90% written) for a while now. Finally finished the whole thing.

Hope it helps.


Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-briscoe-iccrg-prague-congestion-control-00.txt
Date: Tue, 09 Mar 2021 05:35:45 -0800
From: internet-drafts@ietf.org
To: Bob Briscoe <ietf@bobbriscoe.net>, Koen De Schepper <koen.de_schepper@nokia.com>, Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>



A new version of I-D, draft-briscoe-iccrg-prague-congestion-control-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name: draft-briscoe-iccrg-prague-congestion-control
Revision: 00
Title: Prague Congestion Control
Document date: 2021-03-09
Group: Individual Submission
Pages: 30
URL: https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-control-00.txt
Status: https://datatracker.ietf.org/doc/draft-briscoe-iccrg-prague-congestion-control/
Htmlized: https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control
Htmlized: https://tools.ietf.org/html/draft-briscoe-iccrg-prague-congestion-control-00


Abstract:
This specification defines the Prague congestion control scheme,
which is derived from DCTCP and adapted for Internet traffic by
implementing the Prague L4S requirements. Over paths with L4S
support at the bottleneck, it adapts the DCTCP mechanisms to achieve
consistently low latency and full throughput. It is defined
independently of any particular transport protocol or operating
system, but notes are added that highlight issues specific to certain
transports and OSs. It is mainly based on the current default
options of the reference Linux implementation of TCP Prague, but it
includes experience from other implementations where available. It
separately describes non-default and optional parts, as well as
future plans.

The implementation does not satisfy all the Prague requirements (yet)
and the IETF might decide that certain requirements need to be
relaxed as an outcome of the process of trying to satisfy them all.
In two cases, research code is replaced by placeholders until full
evaluation is complete.



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


--------------D2E9325EBF00860BD35C868F--