Re: [tsvwg] New Version Notification for draft-fairhurst-tsvwg-cc-05.txt
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 18 November 2020 10:01 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597043A171E for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 02:01:53 -0800 (PST)
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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SoW5t20dpvVe for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 02:01:51 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9D33A171D for <tsvwg@ietf.org>; Wed, 18 Nov 2020 02:01:51 -0800 (PST)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4C4901B00193 for <tsvwg@ietf.org>; Wed, 18 Nov 2020 10:01:49 +0000 (GMT)
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <160561606055.7956.6346508448924097281@ietfa.amsl.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <f61a1f99-2dc1-ff5f-fccd-09b6cf6cb7f8@erg.abdn.ac.uk>
Date: Wed, 18 Nov 2020 10:01:48 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <160561606055.7956.6346508448924097281@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6bkHyAcJvAgjS7wteGwjPOcL5qE>
Subject: Re: [tsvwg] New Version Notification for draft-fairhurst-tsvwg-cc-05.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 10:01:53 -0000
I'm trying to re-energise this work on finding out what makes an acceptable IETF transport. My intention is that this isn't about the nuances of what makes a good CC, as much as how do we set rules to avoid the excesses of a bad design. That said, the current text draws heavilly on a detailed read of previous RFCs - at the moment this doesn't so much capture the key principles of what matters..., if this is taken further, we need to look forwards (as much as backwards at what RFCs have said). All suggestions are welcome! Gorry On 17/11/2020 12:27, internet-drafts@ietf.org wrote: > A new version of I-D, draft-fairhurst-tsvwg-cc-05.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. > > Name: draft-fairhurst-tsvwg-cc > Revision: 05 > Title: Guidelines for Internet Congestion Control at Endpoints > Document date: 2020-11-17 > Group: Individual Submission > Pages: 26 > URL: https://www.ietf.org/archive/id/draft-fairhurst-tsvwg-cc-05.txt > Status: https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-cc/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-fairhurst-tsvwg-cc > Htmlized: https://tools.ietf.org/html/draft-fairhurst-tsvwg-cc-05 > Diff: https://www.ietf.org/rfcdiff?url2=draft-fairhurst-tsvwg-cc-05 > > Abstract: > This document is for discussion by the TSVWG. It provides guidance > on the design of methods to avoid congestion collapse and to provide > congestion control. Recommendations and requirements on this topic > are distributed across many documents in the RFC series. This > therefore seeks to gather and consolidate these recommendations in an > annexe. Based on these specifications, and Internet engineering > experience, the document provides input to the design of new > congestion control methods in protocols. > > The present document is for discussion and comment by the IETF. If > published, it plans to update or replace the Best Current Practice in > BCP 41, which currently includes "Congestion Control Principles" > provided in RFC2914. > > > > > 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 >
- Re: [tsvwg] New Version Notification for draft-fa… Gorry Fairhurst