Many Thanks for the feedback! Gyan
On Fri, Jan 14, 2022 at 10:48 AM John E Drake <[email protected]> wrote: > Robert is correct on all points. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > *From:* Lsr <[email protected]> *On Behalf Of * Robert Raszuk > *Sent:* Friday, January 14, 2022 4:20 AM > *To:* Gyan Mishra <[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 > > > > *[External Email. Be cautious of content]* > > > > Gyan, > > > > This is not a network discussion. There are well proven techniques to > direct user sessions or user requests to a pool of servers deployed and > operational. All provide robust services. Network plays very little to no > role in that. > > > > There are also lot's of factors involved in making that decision (CPU > load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to > now make IGP to carry it and make routing decisions (even if separate > topology) based on that information. > > > > I do not see this like a move into the right direction. That is my input. > > > > Kind regards, > > Robert. > > > > > > > > > > > > > > > > > > On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra <[email protected]> wrote: > > Robert > > > > Responses in-line > > > > > > > > On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk <[email protected]> wrote: > > 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. > > > > Gyan> Remember this is Anycast proximity based routing along with ECMP > / UCMP flow based load balancing and most vendors modern routers support > some sort of x-tuple ECMP/UCMP hash so the flows would be evenly > distributed, so if you have 10s of 100s of paths, the flows would be evenly > distributed across all the paths. Since it’s Anycast proximity each path > leads to a different Application LB VIP and backend server. So all the TCP > connections would be uniformly distributed across all the paths. > > > > Only the connections hashed to the path with overloaded server would get > reset and it would be no different then if the server went down as the > connections would get reset anyway in that case. > > > > In this case instead of being pinned to a bad connection you are now > reset to a good connection resulting in better QOE for the end user and a > Happy customer. > > > > To me thats a positive not a negative. > > > > A good analogy would be let’s say you are on WIFI and on the same channel > that your neighbors are on and have horrible bandwidth. Do you stay on > that bad channel and limp along all day or to you flip to an unused channel. > > > > Another example is if you have a server that has run out of resources. Do > you fail production traffic off the server taking it out of rotation or let > it stay as is and pray things get better. This draft is a good example of > how IGP can save the day with site metric. > > > > 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. > > > > Gyan> Application load balancing can be done with DNS based GEO load > balancing based on client and server IP database where you have more > discrete control however the failover is much slower. > > > > Leave alone that doing that has potential to immediately overload the > other LB(s)/server(s) too. > > > > Gyan> The idea with Anycast load balancing is that you may have 10 or even > 100s of paths, so if one server fails the load can be evenly distributed > based on statistical multiplexing algorithm calculated by the server teams > engineering the sizing of the server clusters to ensure what you described > won’t happen. > > > > 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul_v4FfHY$> > > > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul6f5yYBY$> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul5Iqp-4w$> > > > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIuljUtRa8M$> > > > > > > > > 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 > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulvnuCJa8$> > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$> > > *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
