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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >> *Date: *Saturday, 27 February 2021 at 9:40 PM >> *To: *Robert Raszuk <[email protected]> >> *Cc: *DECRAENE Bruno IMT/OLN <[email protected]>, Rajesh M < >> [email protected]>, Shraddha Hegde <[email protected]>, William >> Britto A J <[email protected]>, [email protected] <[email protected]> >> *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 <[email protected]> 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= >> [email protected]> 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: *[email protected] <[email protected]> >> *Date: *Monday, 22 February 2021 at 10:56 PM >> *To: *Bruno Decraene <[email protected]>, Rajesh M < >> [email protected]>, Rajesh M <[email protected]>, Shraddha Hegde < >> [email protected]>, William Britto A J <[email protected]>, >> William Britto A J <[email protected]> >> *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 >> [email protected] >> 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 >> [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
