Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well?

Carsten Bormann <cabo@tzi.org> Fri, 17 July 2020 08:57 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 931893A158D for <loops@ietfa.amsl.com>; Fri, 17 Jul 2020 01:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 wwPdsQKWrxLY for <loops@ietfa.amsl.com>; Fri, 17 Jul 2020 01:57:06 -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 ADF403A1589 for <loops@ietf.org>; Fri, 17 Jul 2020 01:57:05 -0700 (PDT)
Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B7Q3b6qq3zyhZ; Fri, 17 Jul 2020 10:56:59 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk>
Date: Fri, 17 Jul 2020 10:56:58 +0200
Cc: Michael Welzl <michawe@ifi.uio.no>, loops <loops@ietf.org>, Liyizhou <liyizhou@huawei.com>
X-Mao-Original-Outgoing-Id: 616669018.167076-db2c486f8bde75d63a73e670365934e8
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB806211-E27B-445E-8638-E31156006E17@tzi.org>
References: <dd240ea2-f1b7-28eb-00ad-bb037c764d4d@erg.abdn.ac.uk> <C5795E6B-14AE-47ED-ADB1-DBEEE37A024A@tzi.org> <e57dbf09-d1d0-e899-f12d-59db29a11f21@erg.abdn.ac.uk> <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <bf0dd742-fa48-695f-7949-cb2b8d40231f@erg.abdn.ac.uk> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/aHuKe6cVT1Bz7ccCzfpeRPrFt48>
Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well?
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: Fri, 17 Jul 2020 08:57:09 -0000

> 
> Still this relies on endpoints to enable ECT(0) processing that might or might not be a hurdle to deploying something else. Do people see LOOPS brings benefit  if the endpoints do not support ECN?

Not the MVP (minimum viable protocol) we are targeting now — doing a one-to-one drop-to-drop signaling doesn’t give you a lot of recovery :-)

Since the issue really is what traffic can be directed to the LOOPS tunnel, it is somewhat trivial to provide benefit once we have better segment-to-path congestion signaling.

>>> As I think I understand, a path increases the workload in response to loss by adding FEC that recovers the loss but hides the increase in rate from the endpoints, instead setting ECN-CE marks to notify of congestion. If the endpoint reacts, then the load stabilizes. Do I need to worry whether the endpoint's reaction to ECN-CE marks is something that the network would also need to monitor, to confirm that CE-marking is actually causing a congestion reaction?
>> Do we do that without LOOPS?
> I think I am concerned enough to worry about this, unless I can see a lot more experience from ietf-tsvwg-tunnel-congestion-feedback.

How can we have any useful ECT traffic at all if we need to suspect that doesn’t react to CE marks?  I’m not sure I understand what the existence of the LOOPS tunnel adds to that (assuming there is some sane overhead limit, such as 20 % — I’m sure 10000 % wouldn’t be so great).

>> (We could add flow-specific circuit breakers, but that creates a lot of processing.)
> 
> Indeed and a circuit-breaker wouldn't be easy to realise (or perhaps appropiate) for short/chatty flows, and that makes me wonder really how much need there is to experimentally investigate what is needed.

A single unruly flow won’t influence a high-mux aggregate.
If there are many unruly flows, the aggregate circuit breaker will trip.
Is there anything interesting in between?

Grüße, Carsten