IETF Logo Mail Archive

Re: [tsvwg] plan for L4S issue #29

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 01 October 2020 12:55 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 52DB93A0FB0 for <tsvwg@ietfa.amsl.com>; Thu, 1 Oct 2020 05:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_NONE=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 QjoVeZGDfy3t for <tsvwg@ietfa.amsl.com>; Thu, 1 Oct 2020 05:54:59 -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 A59C33A0F9C for <tsvwg@ietf.org>; Thu, 1 Oct 2020 05:54:59 -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 3EB7D1B0022B; Thu, 1 Oct 2020 13:54:49 +0100 (BST)
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Pete Heist <pete@heistp.net>, Greg White <g.white@CableLabs.com>, "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> <28cd9795-5b04-4ecb-6e8c-2e12e476f034@erg.abdn.ac.uk> <alpine.DEB.2.20.2010011436510.15604@uplift.swm.pp.se>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <e78527f6-5263-9a33-69d4-8be6b384aa87@erg.abdn.ac.uk>
Date: Thu, 01 Oct 2020 13:54:48 +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: <alpine.DEB.2.20.2010011436510.15604@uplift.swm.pp.se>
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/06RoaxqZ3Mxu1vXk_bR4RH0xeWA>
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:55:01 -0000

On 01/10/2020 13:42, Mikael Abrahamsson wrote:
> On Thu, 1 Oct 2020, Gorry Fairhurst wrote:
>
>> 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?
>
> I don't know where the cut-off is between these, but my worry is that 
> one type of flow might only get few single digit percent of available 
> bw which at slower connections (few megabit/s range) might mean the 
> application using these flows might become unusable.
>
> We've seen this in some tests already, at that time I believe it was 
> during BBR development.
>
> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2016-September/010861.html 
>
>
Right, so I'd agree that stravation of sharing flows is an important 
case - and I appreciate the work done behind the scenes to make sure 
that BBRv2 didn't replicate this sort of problem.

Gorry

v2.23.0 | Report a Bug | By Email