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

Peter Psenak <ppsenak@cisco.com> Wed, 03 March 2021 18:41 UTC

Return-Path: <ppsenak@cisco.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 B983A3A182A for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 10:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.603
X-Spam-Level:
X-Spam-Status: No, score=-9.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 S7_oXea_dhKS for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 10:41:04 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4C73A1826 for <lsr@ietf.org>; Wed, 3 Mar 2021 10:41:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1779; q=dns/txt; s=iport; t=1614796863; x=1616006463; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7NNOxNEz9sLs/heHmW45wzgxk9FPclMKfpkw2wCCXWs=; b=hZdUk1a+dRQvDQyFdIKHw86o+LT1Ne7tlWomLFt4obuJpY8a3kmXUJL8 R3ehHTZlYheKEBzCifWZhHaQ/IZMH3JLkZxCigQt0RMWhJ3QK1naj17Y0 OQSkCsu0185lqS5UtBo0EyATze0fUVTbEZKGBtJ86Ikqr43datl2O8WLB o=;
X-IPAS-Result: A0BbBADu1z9glxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAgU+DdwEnEoRyiQSIKAglA5xLCwEBAQ80BAEBhE0CgXsmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYZDhkUBBSMPAQVBEAsYAgImAgJXBg0IAQGCbIMIrUl2gTKFWINHgUSBDiqNQ0KBSUKBEScMgjkuPodUgl8EgkAGaC9EMAdtP0KQMoMSAaYogwaDL5hlBQcDH4M3ik+FT5ABtxuBayGBWTMaCBsVgyVPGQ2OOI4wQANnAgYBCQEBAwmMEwEB
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,220,1610409600"; d="scan'208";a="33885359"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 18:40:58 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 123IevZ8032740; Wed, 3 Mar 2021 18:40:57 GMT
To: Tony Li <tony.li@tony.li>
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>
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> <1EABA651-2F05-415B-97EF-054507FADEAC@tony.li>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <f935dbc4-6220-5f47-65a4-f642823f594f@cisco.com>
Date: Wed, 03 Mar 2021 19:40:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <1EABA651-2F05-415B-97EF-054507FADEAC@tony.li>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dD2I3xiR-ONc9qj7yYKNAWQ5KKc>
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:41:06 -0000

Tony,

On 03/03/2021 19:14, Tony Li wrote:
> 
> 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.

for all practical purposes that we use it for, the two values of min 
delay that differ by few microsecond can be treated as same without any 
loss of functionality. So it's about the required normalization interval 
- something that can be controlled by the user.

thanks,
Peter



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