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

Tony Li <tony.li@tony.li> Wed, 03 March 2021 17:21 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 636513A1710 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 09:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 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, HTML_MESSAGE=0.001, 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 IyTiyIsYUJNN for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 09:21:40 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 63DC03A170F for <lsr@ietf.org>; Wed, 3 Mar 2021 09:21:40 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id s7so7214557plg.5 for <lsr@ietf.org>; Wed, 03 Mar 2021 09:21:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TiaAdd656rt1ovIu0sTU4SiRtGtODRCTDtxChs5ET5Q=; b=qiOBzzJAhnFAX1NXSCUBix7EDoAEC/rOU4vPeUpDbuFAU8DcxnWe/8PfmQJaDrGpd1 uZtNJQ2oQfqnQdR7FXGGAVvjk1syv4KaD0avnnLxdAwl3R6xGW7FYpZHtk1rT18hTDkZ 9+ZNY8i4OF9UFnLcIvAlSVJjgIGkoXDA3/HlPQTiifrXheR22sA23JYyw/MUZaK291fK pSVWk0gmoSBykXfLMoTO0I6p5hnvqxRQWZHk9zjqVidQwTP9O+jrd2GMcDZ/mrd8mEDs w8qjGFWo7niY7VriaKpL5Y3c4yKEPjEkA+BKkYd/g3O99hCrN5sjjFQbN/oL+5VMQtBD 1pAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TiaAdd656rt1ovIu0sTU4SiRtGtODRCTDtxChs5ET5Q=; b=Izy65hkDgW6VuZlX//eC9boJr8VLo/TVVoMJZ16dWoyUyfZ71gba/Zlam8iGNxHgbb 4ltmBQisWyZlWAPf679GA5v14qeNZPg7tyksB0OQ7qiDaGzT12u5pLdGTPyMD0CBsic8 sU+DD7rkBb8OPv7pJfOFT+zhzciSC2A0KB29LN3P3AWLr/ziwymFJL2ka4B4A9l81lDv E5gP205hd7b8MO4jVJPN69VGgEPeXd41ShI7sjs1E4T2oZtW13/wJ3CInV8ZpiWIt3PP 8nz5SDhGEsCeq6avJkrp57MDly5mSoPjQ1qFO0uyGPgArUv1shpSRLZbG4gWK//g+5vl JFoA==
X-Gm-Message-State: AOAM532/WTotJCSGLl1Nf+85WZ8N8nW3lgDooK8FR2hbZiLTrzX91y0z 96ViieCcWmGxq6TfynIWimzj2qFFIFE=
X-Google-Smtp-Source: ABdhPJwNUTVKw+0yF2qHjaJHzVI5986GJK8rrQHwIut3ynuGkUUNDuPQI9S4L89DMkNER64j49+sPA==
X-Received: by 2002:a17:902:ecc3:b029:e5:d7cc:2a20 with SMTP id a3-20020a170902ecc3b02900e5d7cc2a20mr231920plh.11.1614792099066; Wed, 03 Mar 2021 09:21:39 -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 z137sm27004940pfc.172.2021.03.03.09.21.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Mar 2021 09:21:38 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <52B3A5ED-6ACC-4772-BEF7-085A33A53F31@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C0885D1-80CA-4E76-B7F1-97406C0C6C79"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Wed, 3 Mar 2021 09:21:34 -0800
In-Reply-To: <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com>
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>
To: Peter Psenak <ppsenak@cisco.com>
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>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/bba_Vp0l0VHGsdvo4G5H_-LlTN8>
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 17:21:42 -0000

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.  

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. 

Please note that I’m NOT recommending that we back away. Rather, we should seek to solve the long-standing issue of oscillatory routing.

Regards,
Tony