Re: [LOOPS] How important is congestion detection
Michael Welzl <michawe@ifi.uio.no> Mon, 22 July 2019 21:34 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 254BD1200A3 for <loops@ietfa.amsl.com>; Mon, 22 Jul 2019 14:34:17 -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 GszSAGGxjdxc for <loops@ietfa.amsl.com>; Mon, 22 Jul 2019 14:34:14 -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 B527212001B for <loops@ietf.org>; Mon, 22 Jul 2019 14:34:14 -0700 (PDT)
Received: from mail-mx12.uio.no ([129.240.10.84]) 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 1hpfwh-00056A-Sj; Mon, 22 Jul 2019 23:34:11 +0200
Received: from dhcp-9902.meeting.ietf.org ([31.133.153.2]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hpfwh-000A5O-6M; Mon, 22 Jul 2019 23:34:11 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <CEC56E4C-6C17-4812-A0C4-5B8306C76CE5@tzi.org>
Date: Mon, 22 Jul 2019 17:34:08 -0400
Cc: loops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no>
References: <CEC56E4C-6C17-4812-A0C4-5B8306C76CE5@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 31.133.153.2 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.153.2; envelope-from=michawe@ifi.uio.no; helo=dhcp-9902.meeting.ietf.org;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: FA4D51549FD0A7351FA42BDBE69C3252B18C6364
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/zKW0w2kmY-_X50Hpffa8T_Czpcg>
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: Mon, 22 Jul 2019 21:34:17 -0000
Hi, I can’t parse this: > On Jul 22, 2019, at 5:11 PM, Carsten Bormann <cabo@tzi.org> wrote: > > After the BOF, I had an interesting hallway conversation with Bob Briscoe on congestion feedback signaling, and about congestion detection (i.e., grouping losses into non-congestive and congestive). > > One assumption behind the solutions strawman draft was that it is a valid approach to signal loss events that occur inside the path segment, as CE markings to the end hosts. 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? Trying to guess: is it that this would incur a double-reaction? That would be a strange implementation indeed, if that would happen within the same RTT - but: I thought the whole point is to signal CE *as a replacement* for the loss that LOOPS repairs. So, then… ? Cheers, Michael
- [LOOPS] How important is congestion detection Carsten Bormann
- Re: [LOOPS] How important is congestion detection Michael Welzl
- Re: [LOOPS] How important is congestion detection Carsten Bormann
- Re: [LOOPS] How important is congestion detection Michael Welzl
- Re: [LOOPS] How important is congestion detection Spencer Dawkins at IETF
- Re: [LOOPS] How important is congestion detection Mirja Kuehlewind
- Re: [LOOPS] How important is congestion detection Michael Welzl