[LOOPS] How important is congestion detection

Carsten Bormann <cabo@tzi.org> Mon, 22 July 2019 21:11 UTC

Return-Path: <cabo@tzi.org>
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 888F112008C for <loops@ietfa.amsl.com>; Mon, 22 Jul 2019 14:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 W8ZQJIFcp4nl for <loops@ietfa.amsl.com>; Mon, 22 Jul 2019 14:11:10 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40CC12001B for <loops@ietf.org>; Mon, 22 Jul 2019 14:11:10 -0700 (PDT)
Received: from client-0062.vpn.uni-bremen.de (client-0062.vpn.uni-bremen.de [134.102.107.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45svRK0zJ3zyth; Mon, 22 Jul 2019 23:11:08 +0200 (CEST)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
X-Mao-Original-Outgoing-Id: 585522665.809437-53095e7fe97588208a63db82c6e31465
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 22 Jul 2019 17:11:07 -0400
Message-Id: <CEC56E4C-6C17-4812-A0C4-5B8306C76CE5@tzi.org>
To: loops@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/be3d0QEthRqzCpwUEUz-fdvPpJI>
Subject: [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:11:13 -0000

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.  Congestion detection is then a necessary component of a LOOPS implementation, in order not to be worse than the congestion detection employed by the end hosts.

Congestion detection does not need to be standardized (we probably do want to have a BCP or two at some point, though), so that would not be a theoretical roadblock.

But would it be, in a practical sense?  Do we expect congestion detection along a full path (as Stuart Card said today, against the composition of the statistical behaviors of multiple segments) to be better than in a LOOPS implementation looking at a single path segment?

Grüße, Carsten