IETF Logo Mail Archive

Re: [tsvwg] plan for L4S issue #29

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 01 October 2020 12:29 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 A3F303A0FD8 for <tsvwg@ietfa.amsl.com>; Thu, 1 Oct 2020 05:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_NONE=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 JXJ0kWomI_Wj for <tsvwg@ietfa.amsl.com>; Thu, 1 Oct 2020 05:29:27 -0700 (PDT)
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 5476D3A0FD7 for <tsvwg@ietf.org>; Thu, 1 Oct 2020 05:29:27 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3418A1B0013F; Thu, 1 Oct 2020 13:29:05 +0100 (BST)
To: Pete Heist <pete@heistp.net>, Greg White <g.white@CableLabs.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <202009291549.08TFnvFV068509@gndrsh.dnsmgr.net> <c7080365-233c-5f1e-ef5c-1f42c969042a@erg.abdn.ac.uk> <73562E45-3EE7-43D4-B26B-76478AE19AF8@cablelabs.com> <ae5eb008118ab1b88d65e7712a5e3c54b4207e52.camel@heistp.net>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <28cd9795-5b04-4ecb-6e8c-2e12e476f034@erg.abdn.ac.uk>
Date: Thu, 01 Oct 2020 13:29:04 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <ae5eb008118ab1b88d65e7712a5e3c54b4207e52.camel@heistp.net>
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/S3ZPnQrI0kdgbI4EzifO6JMBdtE>
Subject: Re: [tsvwg] plan for L4S issue #29
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: Thu, 01 Oct 2020 12:29:29 -0000

On 01/10/2020 13:13, Pete Heist wrote:
> On Tue, 2020-09-29 at 22:48 +0000, Greg White wrote:
>> In my opinion, Issue 29 can be closed. RFC3168 detection should
>> continue to evolve and should be referenced in the Operational
>> Guidance draft, but fallback should not be required in the
>> experimental protocol drafts for the reasons outlined in Issue 29,
>> and on the mailing list.
> In my opinion, the issues with bottleneck detection and fallback should
> be fixed, since this was the proposed way to provide safety for the
> alternate meaning of CE being introduced.
>
> The question of whether or not to proceed with these issues still open
> sounds like a separate one, but it seems like closing issues without
> fixing them would make it hard for someone who wanted to review and
> understand what issues are still open.
>
> Pete
>
To be clear, is there a "safety" concern with respect to congestion 
collapse from overload, or is it an issue concerning relative fairness 
between flows?

Gorry

Gorry

v2.23.0 | Report a Bug | By Email