Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */
But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you *s/connection/all connections/* then you quickly realize that what is proposed here is a disaster. Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network. Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too. For me the conclusion is that IGP transport level is not the proper layer to address the requirement. Cheers, Robert. On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra <[email protected]> wrote: > > Hi Les > > Agreed. > > My thoughts are that the context of the draft is based on an Anycast VIP > address of a server which is proximity based load balancing and not > necessarily ECMP/UCMP and only if the proximity is the same for multiple > paths to the Anycast VIP would there be a ECMP/UCMP possibility. > > Let’s say if it’s proximity based and one path is preferred, the flow will > take that path. So now the server you are on gets overloaded and a site > cost gets advertised in the IGP at which point the connection receives a > TCP reset and flow re-establishes on the alternate path based on the site > cost and remains there until the server goes down or gets overloaded or a > better path comes along. > > For ECMP case, ECMP has flow affinity so the flow will stay on the same > path long lived until the connection terminates. > > So now in ECMP case the flow hashed to a path and maintains its affinity > to that path. Now all of sudden the server gets overloaded and we get a > better site cost advertised. So now the session terminates on current path > and establishes again on the Anycast VIP new path based on the site cost > advertised. > > The failover I believe results in the user refreshing their browser which > is better than hanging. > > As the VIP prefix is the only one that experiences reconvergence on new > path based on site cost if there is any instability with the servers that > will be reflected to the IGP Anycast prefix as well. > > Is that a good or bad thing. I think if you had to pick your poison as > here the issue Linda is trying to solve is a server issue but leveraging > the IGP to force re-convergence when the server is in a half baked state > meaning it’s busy and connections are being dropped or very slow QOE for > end user. If you did nothing and let it ride the the user would be stuck > on a bad connection. > > So this solution dynamically fixed the issue. > > As far as oscillation that is not a big deal as you are in a much worse > off state connected to a dying server on its last leg as far as memory and > CPU. > > This solution I can see can apply to any client / server connection and > not just 5G and can be used by enterprises as well as SP for their > customers to have an drastically improved QOE. > > I saw some feedback on the TLV and I think once that is all worked out I > am in favor of advancing this draft. > > Kind Regards > > Gyan > > > On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > >> Gyan – >> >> >> >> The difference between ECMP and UCMP is not significant in this >> discussion. >> >> I don’t want to speak for Robert, but for me his point was that IGPs can >> do “multipath” well – but this does not translate into managing flows. >> >> Please see my other responses on this thread. >> >> >> >> Thanx. >> >> >> >> Les >> >> >> >> >> >> *From:* Gyan Mishra <[email protected]> >> *Sent:* Wednesday, January 12, 2022 5:26 PM >> *To:* Robert Raszuk <[email protected]> >> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Linda Dunbar < >> [email protected]>; [email protected] >> *Subject:* Re: [Lsr] Seeking feedback to the revised >> draft-dunbar-lsr-5g-edge-compute >> >> >> >> >> >> Robert >> >> >> >> Here are a few examples of UCMP drafts below used in core and data center >> use cases. >> >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 >> >> >> >> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 >> >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth >> >> >> >> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz >> >> >> >> >> >> >> >> There are many use cases in routing for unequal cost load balancing >> capabilities. >> >> >> >> Kind Regards >> >> >> >> Gyan >> >> >> >> On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk <[email protected]> wrote: >> >> Linda, >> >> >> >> > IGP has been used for the Multi-path computation for a long time >> >> >> >> IGP can and does ECMP well. Moreover, injecting metric of anycast server >> destination plays no role in it as all paths would inherit that external to >> the IGP cost. >> >> >> >> Unequal cost load balancing or intelligent traffic spread has always been >> done at the application layer *for example MPLS* >> >> >> >> Thx a lot, >> >> R. >> >> >> >> On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <[email protected]> >> wrote: >> >> Robert, >> >> >> >> Please see inline in green: >> >> >> >> *From:* Robert Raszuk <[email protected]> >> *Sent:* Wednesday, January 12, 2022 1:00 PM >> *To:* Linda Dunbar <[email protected]> >> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; [email protected] >> *Subject:* Re: [Lsr] Seeking feedback to the revised >> draft-dunbar-lsr-5g-edge-compute >> >> >> >> Hi Linda, >> >> >> >> *[LES:] It is my opinion that what you propose will not achieve your >> goals – in part because IGPs only influence forwarding on a per packet >> basis – not a per flow/connection basis.* >> >> *[Linda] Most vendors do support flow based ECMP, with Shortest Path >> computed by attributes advertised by IGP.* >> >> >> >> I am with Les here. ECMP has nothing to do with his point. >> >> >> >> [Linda] Les said that “IGP only influence forwarding on a per packet >> basis”. I am saying that vendors supporting “forwarding per flow” with >> equal cost computed by IGP implies that forwarding on modern routers are >> no longer purely per packet basis. >> >> >> >> >> >> Draft says: >> >> >> >> *When those multiple server instances share one IP address (ANYCAST), the >> transient network and load conditions can be incorporated in selecting an >> optimal path among server instances for UEs.* >> >> >> >> So if we apply any new metric to indicate load of a single anycast >> address how is this going to help anything ? >> >> >> >> [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple >> paths with the same routing distance. >> >> >> >> >> >> You would need a mechanism where the network is smart and say per src-dst >> tuple or more spreads the traffic. IGP does not play that game today I am >> afraid. >> >> [Linda] There is one SRC and multiple paths to one DST. IGP has been used >> for the Multi-path computation for a long time. >> >> >> >> Thank you, Linda >> >> >> >> Thx a lot, >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> -- >> >> [image: Image removed by sender.] <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email [email protected] <[email protected]>* >> >> *M 301 502-1347* >> >> >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
