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

Peter Psenak <ppsenak@cisco.com> Wed, 03 March 2021 18:04 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 F06D93A17B2 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 10:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 L20eOaszZJOr for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 10:04:26 -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 23A893A17B0 for <lsr@ietf.org>; Wed, 3 Mar 2021 10:04:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2643; q=dns/txt; s=iport; t=1614794666; x=1616004266; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fTZ8o6ixb+Lrd6pnVHI6wl7RR2Jxza1olG8v2zz/OGI=; b=UrEmeS4P51ofgG3GmKbPp5kt1nUUl/I+ReWxH5jvkzyJwSXBWq4BWtE8 4IsD3Cvr92AkFFtY0bN8VH8YZeIFLGacfv00SZ/d3GWRjnYH/YD/eHXvw ZCwcAtjtwcmkqqduDFZ/E6MQnjoUTxogjxhvOg3QJBDA67f6Kf1j1i4Pe M=;
X-IPAS-Result: =?us-ascii?q?A0AABACdzj9glxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DdwEnEoRyiQSIKS0DnEsLAQEBDzQEAQGETQKBeyY4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEFAEBAQEBAQEBhkOGRAEBAQMBIw8BBUEQCxgCAiYCAlcGDQgBA?= =?us-ascii?q?YJsgmchrU52gTKFWINHgUSBDiqNQ0KBSUKBESeCRS4+h1SCXwSCQAYHYXMwB?= =?us-ascii?q?yRJFZEeV4I7AaYogwaDL5hlBQcDH4M3ik+FT5ABsh2EfoFrIYFZMxoIGxWDJ?= =?us-ascii?q?U8ZDY44jjBAA2cCBgEJAQEDCYwTAQE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,220,1610409600"; d="scan'208";a="33884499"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 18:04:22 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 123I4LVH000564; Wed, 3 Mar 2021 18:04:21 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>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <e5190522-3a8b-2d6e-c2fe-646049689cc4@cisco.com>
Date: Wed, 3 Mar 2021 19:04:21 +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: <52B3A5ED-6ACC-4772-BEF7-085A33A53F31@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-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/8E5I3fuBD0ZofiYS3RYZJu0CFDw>
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:04:28 -0000

Tony,

On 03/03/2021 18:21, Tony Li wrote:
> 
> Peter,
> 
>>> Link delay was dynamic before this draft.  As William mentioned, 
>>> TWAMP can already be used to provide a dynamic measurement of link 
>>> delay.  That, coupled with the link delay metric already gave us 
>>> dynamic path computation requirements and the possibilities of 
>>> oscillation and instability. We have chosen to charge ahead, without 
>>> addressing those concerns already.
>>
>> TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the 
>> other side this value is calculated based on multiple measurements 
>> over period of time and an average is used. Also, smart 
>> implementations can normalize the value so that a small fluctuation of 
>> the delay is not causing the traffic to shift or cause ECMP loss.
>>
>> What is important here is that the Min Unidirectional Link Delay is a 
>> link characteristic, not something that is affected by the amount of 
>> traffic on the link or subject to queuing delay. Same applies to 
>> Maximum link bandwidth.
> 
> 
> I do understand that the minimum link delay is not meant to include 
> queuing delay. That, however, does NOT make it a constant.

I never claimed it is constant. It should not be affected though by the 
amount of traffic on the link itself, but rather by the characteristics 
of the underlying physical path.

> 
> 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. There are implementations that do that today. 
You normalize the measured value so that values that are close enough 
are advertised as same value. That works well for min delay case, which 
does not change significantly very often.

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

thanks,
Peter

> 
> Regards,
> Tony
>