Re: [LOOPS] How important is congestion detection

Michael Welzl <michawe@ifi.uio.no> Tue, 30 July 2019 20:29 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6564E120108 for <loops@ietfa.amsl.com>; Tue, 30 Jul 2019 13:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0UGAGz7q1VcI for <loops@ietfa.amsl.com>; Tue, 30 Jul 2019 13:29:21 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 61318120024 for <loops@ietf.org>; Tue, 30 Jul 2019 13:29:21 -0700 (PDT)
Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hsYkI-00009X-Fm; Tue, 30 Jul 2019 22:29:18 +0200
Received: from 91.141.3.254.wireless.dyn.drei.com ([91.141.3.254] helo=[192.168.1.113]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hsYkH-000Aqi-3S; Tue, 30 Jul 2019 22:29:18 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <2693E1C9-B778-48CD-9790-EEE70DAFDADF@kuehlewind.net>
Date: Tue, 30 Jul 2019 22:29:11 +0200
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Carsten Bormann <cabo@tzi.org>, loops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7548531E-37C6-4643-9E60-E848891FAFFC@ifi.uio.no>
References: <CEC56E4C-6C17-4812-A0C4-5B8306C76CE5@tzi.org> <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> <5EEF6351-EC39-40A1-8A99-876B53094B08@ifi.uio.no> <CAKKJt-fknF=ieOZDTBjsdNCJST7KnUZzXmL=CD55GoMDag74uw@mail.gmail.com> <2693E1C9-B778-48CD-9790-EEE70DAFDADF@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 91.141.3.254 is neither permitted nor denied by domain of ifi.uio.no) client-ip=91.141.3.254; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.113];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 69621AAD0C25FC7CF81F47A325C57B2281E0A6D2
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/RRXrrFfyeLwQxElh_UExBXChORs>
Subject: Re: [LOOPS] How important is congestion detection
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 20:29:25 -0000

Yes, and I hope less so with every version.
I also hope that we don’t have to design the Internet around BBR now.


Sent from my iPhone

> On 30 Jul 2019, at 12:14, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> BRR is ignoring loss (up to some % of loss rate) while it will always react to CE.
> 
> 
>> On 23. Jul 2019, at 16:45, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>> 
>> FWIW, 
>> 
>> On Mon, Jul 22, 2019 at 6:51 PM Michael Welzl <michawe@ifi.uio.no> wrote:
>> 
>> 
>>> On Jul 22, 2019, at 6:17 PM, Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> Sorry for typing a message from a heated BOF where I was representing a WG that needs a specific outcome…
>>> 
>>>>> Bob pointed out that some end host implementations today interpret CE as definite congestion events, while applying congestion detection to loss signals, so this conversion might be counterproductive.
>>>> 
>>>> The last sentence - I don't understand it (“interpret CE as definite… while applying detection to loss” - huh?). What does it mean? Or, maybe: what’s the issue here?
>>> 
>>> What I think Bob meant: An end-host noticing a loss might make its own determination (a.k.a. congestion detection) whether that is a reason to slow down or not.
>>> An end-host getting a CE might simply assume this is indeed congestion, and always slow down.  So, CE > loss, and a simple replacement of loss by CE worsens throughput.
>> 
>> Ok, thanks!  now I understand that the statement is indeed what I thought, but it still makes zero sense to me. See below:
>> 
>> 
>>>> I thought the whole point is to signal CE *as a replacement* for the loss that LOOPS repairs. So, then… ?
>>> 
>>> If CE > loss, replacing loss by CE is not enough, we need to vet the losses via a LOOPS-side congestion detection that is as good as the one as the end-host would do, or (preferably) better.
>> 
>> RFC 3168 says CE = loss. RFC 8311 finally allows us to diverge from this rule, which we used in RFC to state: “CE < loss”.
>> L4S of course also does “CE < loss”, albeit in much more elaborate ways.
>> 
>> However: "CE > loss” is truly weird to me - perhaps this IS now allowed by RFC 8311  :-D    but if it’s spec’ed then it must be an April 1 RFC.
>> 
>> What am I missing, Bob?
>> 
>> I was hoping CE > loss was a typo, myself.
>> 
>> Spencer
>> 
>> 
>> Cheers,
>> Michael
>> 
>> -- 
>> LOOPS mailing list
>> LOOPS@ietf.org
>> https://www.ietf.org/mailman/listinfo/loops
>> -- 
>> LOOPS mailing list
>> LOOPS@ietf.org
>> https://www.ietf.org/mailman/listinfo/loops
>