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

Tony Przygienda <tonysietf@gmail.com> Mon, 01 March 2021 20:45 UTC

Return-Path: <tonysietf@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 504E03A22A4 for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 12:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.455
X-Spam-Level:
X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=0.132, URI_NOVOWEL=0.5] autolearn=unavailable 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 eCvwN1-8naGm for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 12:45:32 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 0ADDE3A22A1 for <lsr@ietf.org>; Mon, 1 Mar 2021 12:45:32 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id 81so15638108iou.11 for <lsr@ietf.org>; Mon, 01 Mar 2021 12:45:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gE0+AMfSo0Jn0qUj9h8ShEWKCKVqyV3UIcr5MkSsmho=; b=uib5iA2n3sF8FIqq6NS6S1nq9PR44Wv0dmlhdJrHmXpaoLqCor+A4/owTJNdsPYXvL mQkUDsGpAG98S9SRkiVln923k3Ozm+fJGblEv9VUU/iBPicGSPy2agerhm3OGqZuDiMF zHyfBF4x10wVrQmR7Z/nE0E55vvwKOQUTn2322bpF0euTFHtrUcrQvdvOybjgij3pyxf v4TS27CerSl4ypS3qGYX85S113cXcuGQWLug5YFDvKEys+hVa3gmLmHfQ73Yq/vx8rFn ILxeRgN10l/fj8iWQXrNP0zzSwe5UNLGAT8qES563YbTL4ENEtPsLHnxhdFbobhJI+dQ EfmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gE0+AMfSo0Jn0qUj9h8ShEWKCKVqyV3UIcr5MkSsmho=; b=bJj01VlA034rhsUWr+Zw9XjNGI7L6LL2uKeYGfiRWEaVJqgDXoF38Z2e+I1gCXx2R3 2956ruIHDvz2iCcWAAEOOxFaIZ0ZAmXlQZp2Va1v/vzDdxsABCXNXIO93RdTPrFSn/m+ Y4K5+GeZMPqTG6OwbTaiQ0IHW4ndhTrU0sFd50Huy6hqaGujKcI7VmTYQBmy6rzWxnkH 53bJiE+JenssxwT3rEcMt54WvvSx4tetzdQnNdUba/gJlzkDeEJq+oxLE7+nakeYiUj9 hFMaUqvJo7sPvyKAMgLlO+Aq02KfQgh8P94RxpiRogiTgK3frb/M2yoro6Vozb+KJbsN wINw==
X-Gm-Message-State: AOAM5302WUgMfktp3aOiTvQ3Q4plUkoaaXCTQ4ayxvoh6Cae8taqGY5+ BcLvGxe4RJoa/QE8h5vA6UyYVNijSZqSIcVfIFk=
X-Google-Smtp-Source: ABdhPJyf1f9IT50u4P4LqtbATqWSLpDpBAHUwwUdJnObfW+/hMmz6hADxv+AMi8HFsr547i8WV6WLetLMKsJf+3nqak=
X-Received: by 2002:a05:6638:2bb:: with SMTP id d27mr17648441jaq.98.1614631530506; Mon, 01 Mar 2021 12:45:30 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Mon, 1 Mar 2021 21:44:54 +0100
Message-ID: <CA+wi2hOO-w4bFLkDfuf11c-7uoNuWbzW5=c9EB+tY0Hr417k=Q@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Tony Li <tony.li@tony.li>, 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-Type: multipart/alternative; boundary="000000000000d1adf105bc7fb287"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7ggwfhhL4neoJcAENLgqj_2ShIg>
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: Mon, 01 Mar 2021 20:45:35 -0000

dyanmic queue lengths are still poor indicators of delay (in routing
network wide sense @ realistic routing flood/processing resolution),
nothing changed much since 1980 AFAIK

https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf

delay/jitter can be talked about meaningfully if the context of the
topologies involved is controlled, pretty much stuff Lou's DETNET is
chewing

my 2c

-- tony



On Mon, Mar 1, 2021 at 9:22 PM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Tony,
>
> Constructing arbitrary topologies with bw constrain is useful work. For
> example I want to create a topology without links of the capacity less then
> 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3
> 1Gbps links nicely doing ECMP I will not include those which may be a
> problem.
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
> Thx,
> R.
>
>
>
>
>
> On Mon, Mar 1, 2021 at 7:42 PM Tony Li <tony.li@tony.li> wrote:
>
>>
>> Hi William, Gyan, Robert, Tony, et. al.,
>>
>> Please permit me to wax a bit philosophic here.
>>
>> William is exactly correct that the goal is not to make FlexAlgo deal
>> with reservations like RSVP does.  Without some kind of setup protocol or
>> global computation, that’s simply not possible. Moreover that’s not the
>> real problem that we’re out to solve.
>>
>> Reservations are just a first order approximation to a traffic flow in
>> any case. We characterize them as having a fixed constant bandwidth, but we
>> all know that that is far from the truth. Each flow is diurnal and
>> fractally bursty. Every user who ever clicks on a link creates bandwidth
>> demand and while the Law of Large Numbers helps us out with some averages
>> we all know that we have no good way of characterizing the traffic that
>> we’re trying to carry. Claiming that it is a single 12Gbps LSP is truly a
>> huge over simplification and a good step towards solving the real problem.
>>
>> So what is the real problem that we’re trying to solve?
>>
>> We are trying to not drop packets.
>>
>> Dropping packets is bad because it forces retransmissions and impacts
>> someone’s Internet experience. Dropping packets is our response to
>> congestion events. If we could manage to have a network that never
>> congested and always delivered packets without giant latency, all would be
>> good.
>>
>> To date, we have created traffic engineering mechanisms to help us steer
>> traffic so that we could delivery traffic without congesting. It has been a
>> means to an end. The mechanisms that we’ve created have a non-trivial
>> overhead and approximate our goals, but they do NOT preclude, anticipate,
>> or avoid congestion. They do not react when we have unexpected inputs. We
>> do extensive pre-computation to deal with even single failures and have no
>> serious mechanisms that handle multiple failures.
>>
>> Right now, FlexAlgo does nothing to help with bandwidth management.
>> Wiilliam et. al., are proposing some first steps, which are to be
>> encouraged. Much more will be needed, not to recreate legacy mechanisms but
>> because we should be striving for a more sophisticated, real-time approach
>> to bandwidth management and congestion avoidance.
>>
>> Regards,
>> Tony
>>
>>
>> On Mar 1, 2021, at 2:24 AM, William Britto A J <
>> bwilliam=40juniper.net@dmarc.ietf.org> wrote:
>>
>> Hi Gyan,
>>
>> This draft aims to provide the protocol constructs to define a
>> flex-algorithm which is suitable for sending high bandwidth traffic. Flex-Algo
>> is a very useful feature for network consolidation use-cases which requires
>> different metric-types for SPF. We are trying introduce the protocol
>> constructs to simplify the use of metric based on bandwidth via
>> Flex-Algo.
>>
>> This draft does not attempt to do bandwidth management nor reservation
>> like what RSVP does. For LDP based networks that use igp metric relative to
>> bandwidth, Flex-Algo provides an easy alternate.
>>
>> Thanks,
>> William
>>
>>
>> *From: *Gyan Mishra <hayabusagsm@gmail.com>
>> *Date: *Saturday, 27 February 2021 at 9:40 PM
>> *To: *Robert Raszuk <robert@raszuk.net>
>> *Cc: *DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>om>, Rajesh M <
>> mrajesh@juniper.net>gt;, Shraddha Hegde <shraddha@juniper.net>et>, William
>> Britto A J <bwilliam@juniper.net>et>, lsr@ietf.org <lsr@ietf.org>
>> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>> *[External Email. Be cautious of content]*
>>
>>
>> Hi William & Co-authors
>>
>> From first read of the draft it does appear your are trying to apply RSVP
>> TE PCALC path and reserve message link attributes constraints such as
>> concept of affinity bits to exclude low bandwidth or delay of individual
>> links without taking into account all of what RSVP TE is reserving of
>> bandwidth in the end to end path with the Path and Reserve message.  As
>> mentioned Looking at individual links will not provide the end to end path
>> view or bandwidth requirements for the entire path to be reserved as
>> accomplished by RSVP TE.
>>
>> As Tony and Robert have mentioned I agree this is a good first step but
>> does need more refinement to make useful.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk <robert@raszuk.net> wrote:
>>
>> Hi William & co-authors,
>>
>> I read the draft and have two basic questions.
>>
>> 1.
>> Both bw & delay can be used as defined in the draft to construct new
>> forwarding topologies. But how practical such topologies would be in the
>> real life when 40GB links may be heavily occupied with bursty traffic and
>> 10G links can sit idle ? I suppose you are trying to address the case where
>> say 12 gbps holographic stream needs to be sent across a network.. But then
>> I don't think if sending it in a single flow instead of spreading into many
>> sub-flows and use as much as possible ecmp would not be a better option.
>>
>> 2.
>> Likewise how good is my accumulated link delay value if in between there
>> are deep buffer network elements and say egress queuing to each link (which
>> max is unaccounted for in your draft) can significantly alter the end to
>> end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link
>> basis (still as static value).  So if some traffic is delay sensitive we
>> will have a much better accuracy not to get into a trap of queuing related
>> delays.
>>
>> Thx a lot,
>> Robert.
>>
>>
>> On Fri, Feb 26, 2021 at 8:37 AM William Britto A J <bwilliam=
>> 40juniper.net@dmarc.ietf.org> wrote:
>>
>> All,
>>
>>
>> We would like to draw your attention to a new ID:
>> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8sz2YPxkw$>
>>
>>
>> The draft talks about introducing link bandwidth related constraints in
>> Flex-Algorithm which can be used to define a Flex-Algorithm based on
>> bandwidth based metric.
>>
>>
>> Please review. Any questions and comments are welcome.
>>
>>
>> Thanks,
>> William
>>
>>
>>
>>
>>
>> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
>> *Date: *Monday, 22 February 2021 at 10:56 PM
>> *To: *Bruno Decraene <bruno.decraene@orange.com>om>, Rajesh M <
>> mrajesh@juniper.net>gt;, Rajesh M <mrajesh@juniper.net>et>, Shraddha Hegde <
>> shraddha@juniper.net>gt;, William Britto A J <bwilliam@juniper.net>et>,
>> William Britto A J <bwilliam@juniper.net>
>> *Subject: *New Version Notification for
>> draft-hegde-lsr-flex-algo-bw-con-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
>> has been successfully submitted by Shraddha Hegde and posted to the
>> IETF repository.
>>
>> Name:           draft-hegde-lsr-flex-algo-bw-con
>> Revision:       00
>> Title:          Flexible Algorithms Bandwidth Constraints
>> Document date:  2021-02-22
>> Group:          Individual Submission
>> Pages:          21
>> URL:
>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$
>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$>
>> Status:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$>
>> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$>
>> Htmlized:
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$
>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$>
>>
>>
>> Abstract:
>>    Many networks configure the link metric relative to the link
>>    capacity.  High bandwidth traffic gets routed as per the link
>>    capacity.  Flexible algorithms provides mechanisms to create
>>    constraint based paths in IGP.  This draft documents a set of
>>    bandwidth related constraints to be used in Flexible Algorithms.
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org
>> <https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8vQC8uTvg$>
>> .
>>
>> The IETF Secretariat
>>
>>
>> Juniper Business Use Only
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8umPEf2Zg$>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8umPEf2Zg$>
>>
>> --
>>
>>
>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8vByLZnBg$>
>> *Gyan Mishra*
>> *Network Solutions Architect *
>>
>>
>> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>>
>>
>> Juniper Business Use Only
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>