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

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>, Rajesh M <
>> mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, William
>> Britto A J <bwilliam@juniper.net>, 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>, Rajesh M <
>> mrajesh@juniper.net>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <
>> shraddha@juniper.net>, William Britto A J <bwilliam@juniper.net>,
>> 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
>