Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Gyan Mishra <[e-mail]>]

Many Thanks for the feedback!

Gyan

On Fri, Jan 14, 2022 at 10:48 AM John E Drake <[e-mail]> wrote:

> Robert is correct on all points.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr <[e-mail]> *On Behalf Of * Robert Raszuk
> *Sent:* Friday, January 14, 2022 4:20 AM
> *To:* Gyan Mishra <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; Linda Dunbar <
> [e-mail]>; [e-mail]
> *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 <[e-mail]> wrote:
>
> Robert
>
>
>
> Responses in-line
>
>
>
>
>
>
>
> On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk <[e-mail]> 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 <[e-mail]> 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) <
> [e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, January 12, 2022 5:26 PM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; Linda Dunbar <
> [e-mail]>; [e-mail]
> *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 <[e-mail]> 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 <[e-mail]>
> wrote:
>
> Robert,
>
>
>
> Please see inline in green:
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Wednesday, January 12, 2022 1:00 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
> *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
> [e-mail]
> 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 [e-mail] <[e-mail]>*
>
> *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 [e-mail] <[e-mail]>*
>
> *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 [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*