Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Tony Li <tony.li@tony.li> Wed, 03 March 2021 18:14 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FCB3A17D2 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 10:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3KqaLJcDi6Xa for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 10:14:07 -0800 (PST)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7443A17D0 for <lsr@ietf.org>; Wed, 3 Mar 2021 10:14:06 -0800 (PST)
Received: by mail-pj1-x1036.google.com with SMTP id b15so4678292pjb.0 for <lsr@ietf.org>; Wed, 03 Mar 2021 10:14:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zyr5bfVcH1M7nLx9hmc/nQLcRw/bwRFfIDgWsclV+08=; b=S0Gr9i/hFLtC76WwClVqXYymSUkdMaUM1Z0B71c93gJaVix+9ekuhAbCPBHFCBnDBQ NaglUW+3F+1s9NtFiXn+qBeaTmTV3cT5n3t0miQWvCH9lhKjnaOIrhZsQqrowIUVO+d/ XavrUbRieRfrBeO+TqqZUchWlwkj3Sjs9XNYGs8l/sKgDBhkw8bG4Qe/OC25eqASfWwv MSixKwUGSMWfRsd+bn60gVt6xO6WiyttiOIXgOmSkeSqxntiKfp46eYmVF2ugfRpu/dA vl48ZJtE8TN2AN6k3RMLeVJ+b+QR9Z9uQ0SibXGwowUJ7LCDKoFGK9kQ2B7gHVZlvPsQ zYvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=zyr5bfVcH1M7nLx9hmc/nQLcRw/bwRFfIDgWsclV+08=; b=AHZCjdTz3lbaHUYbdWoqiZaxdLfuGP1U15jUemHEhOUurCW/Dn1V3/n4Z7bbbnqNvm 3pmpQexEtmoMDvVWPEuusFwneLbvE05pvTfcYK2TKNt+do6Ct/qa3T3ghkVgyC8EAxaD gwhXfjost8V0Q9hsCGNsfPpImibwjrj713C94H/3KyPNjg+jx+v4crI/a7g5/5H0KbqA As/EEXvcN+BlP1xkwYUu2QMcdILot4eyhnNfC+DgVyHusXwy/HqeLxbpU6Wbov6pSCN3 j+crAWeyhuMQng5dAaCqr1N04SmfgdwgFMDiIabUlRl6v1Y3XrzmFSceS5DICY5irhbo q/1g==
X-Gm-Message-State: AOAM5309SOJSuEDWPuhUkTO8MNTr0W++x6mXFHl6rDcR+PnJR2U/zrYi vbxPcv3gLAe5m8dm3VcNSifO5ZEVtcM=
X-Google-Smtp-Source: ABdhPJzW/9ajw8nks/gRWh3ZfXLn+jXNYsBUyCDEOmSEC1ta3kX6I6xwpFYmPoUTbGFNXro5uAA3Xw==
X-Received: by 2002:a17:902:edc6:b029:e4:6dba:415e with SMTP id q6-20020a170902edc6b02900e46dba415emr304897plk.65.1614795245308; Wed, 03 Mar 2021 10:14:05 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id w17sm22196411pgg.41.2021.03.03.10.14.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Mar 2021 10:14:04 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <e5190522-3a8b-2d6e-c2fe-646049689cc4@cisco.com>
Date: Wed, 03 Mar 2021 10:14:03 -0800
Cc: Robert Raszuk <robert@raszuk.net>, Gyan Mishra <hayabusagsm@gmail.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EABA651-2F05-415B-97EF-054507FADEAC@tony.li>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com> <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.com> <CABNhwV0UKB=HaMs9eLvvp4fVLPsEtJhQ2xFmwY80sqBNDFRudQ@mail.gmail.com> <DM5PR0501MB38006C4B638AD2AB6A7731B5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com> <7C67D01F-24DB-4450-8587-E004CAFBBEBC@tony.li> <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com> <08882555-009B-4068-ABB0-20B0D165D722@tony.li> <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com> <52B3A5ED-6ACC-4772-BEF7-085A33A53F31@tony.li> <e5190522-3a8b-2d6e-c2fe-646049689cc4@cisco.com>
To: Peter Psenak <ppsenak@cisco.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1W6Gh0m7bR926LLncCeSnryuI74>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 18:14:09 -0000

Peter,

>> There are several link types in use that exhibit variable delay: satellite links (e.g., Starlink), microwave links, and ancient link layers that deliver reliability through retransmission.
>> Any of these (and probably a lot more) can create a noticeable and measurable difference in TWAMP. That would be reflected in an FA metric change. If you imagine a situation with multiiple parallel paths with nearly identical delays, you can easily imagine an oscillatory scenario.   IMHO, this is an outstanding concern with FA.
> yes, and that is what I referred to as "delay normalization", which can avoid that oscillation.


It can also negate the benefits of the feature. One might well imagine that Starlink would want to follow a min-delay path for optimality.  If the delay variations are “normalized” out of existence, then the benefits are lost.  The whole point is to track the dynamics.


>> Please note that I’m NOT recommending that we back away. Rather, we should seek to solve the long-standing issue of oscillatory routing.
> 
> not that I disagree. History tells us that the generic case of oscillation which is caused by the traffic itself is a hard problem to solve.


Any oscillation is difficult to solve.  Positive feedback certainly can exacerbate the problem. But solving hard problems is why we are here.

Yours in control theory,
Tony