IETF Logo Mail Archive

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:26 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 CAF533A155A for <loops@ietfa.amsl.com>; Fri, 17 Jul 2020 01:26:57 -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 4iw1rcROvqjZ for <loops@ietfa.amsl.com>; Fri, 17 Jul 2020 01:26:55 -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 44F7E3A1559 for <loops@ietf.org>; Fri, 17 Jul 2020 01:26:54 -0700 (PDT)
Received: from client-0175.vpn.uni-bremen.de (client-0175.vpn.uni-bremen.de [134.102.107.175]) (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 4B7PNn5n9jz17sr; Fri, 17 Jul 2020 10:26:49 +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: <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk>
Date: Fri, 17 Jul 2020 10:26:49 +0200
Cc: loops <loops@ietf.org>, Liyizhou <liyizhou@huawei.com>, Michael Welzl <michawe@ifi.uio.no>
X-Mao-Original-Outgoing-Id: 616667209.11756-3fd61760258dd2a8d20a5d86278346cd
Content-Transfer-Encoding: quoted-printable
Message-Id: <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@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>
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/JexjdMM9R9xTe7sIdZ33OEBhJRY>
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:26:58 -0000

> 
> OK, so I think this means the plan would be to target chatty flows, but only for endpoints that have  enabled ECN?

Yes.  (I don’t know if you group short flows under chatty.)

> Am I correct in assuming that this is classic ECN, using ECT(0)?

If there is another form of ECN, with defined rules how to convert losses into marks, these could be added.  But I don’t think there is, at this point in time.

> 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?

(We could add flow-specific circuit breakers, but that creates a lot of processing.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email