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

[Robert Raszuk <[e-mail]>]

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 <[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://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 <[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
>>
>> --
>>
>> [image: Image removed by sender.] <http://www.verizon.com/>
>>
>> *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*
>
>