Re: [Idr] [Can] Proposed CAN WG charter for discussion

[Robert Raszuk <[e-mail]>]

Dear 王雪伟1,

> I also agree with network-service centric approach for it can
> provide more fine-grained traffic streering based on the x tuple,

Actually applications can use much wider lookup criteria as compared to
what is sent in the packet. So if the objective is to enhance selection
based on more parameters clearly network-centric CAN will be inferiori.

That is not to say that it can not be made to work with sufficient
constraints and thresholds on the state injected to the network. However
such constraints and thresholds almost always get pushed further
and further as time goes on.

We see right here that you are already asking for a routing decision lookup
to be based not just on destination address but X tuple from the packet.

So what we now have on ingress is this:

ANYCAST_DST
         |
          ------------ ANYCAST_PATH_1
         |
          ------------ ANYCAST_PATH_2
         |
          ------------ ANYCAST_PATH_3
         |
          ------------ ANYCAST_PATH_N

Each ANYCAST_PATH comes with a set of compute constraints. And now you want
to select the actual forwarding PATH using EPE based on x-tuple from the
packet. And likely you want such forwarding to be done at hardware line
rate too.

It may look easy on ppt or in the draft vs at scale in real network
elements - and that's my point.

Kind regards,
R.


On Sun, Jan 29, 2023 at 9:09 AM 王雪伟1 <[e-mail]> wrote:

> I also agree with network-service centric approach for it can provide more
> fine-grained traffic streering based on the x tuple, also for it can help
> some dumb terminal(cameras、or some IoT terminals) to do optimal decision.
> I am willing to join the discussion and do something about the
> network-service centric approach, and the revised charter seems clearer for
> me, and the issues which CAN will introduce indeed need to be concerned and
> discussed.
> From: "Joel Halpern"<[e-mail]>
> Date:  Sun, Jan 29, 2023, 03:24
> Subject:  Re: [Idr] [Can] Proposed CAN WG charter for discussion
> To: "Robert Raszuk"<[e-mail]>, "Peng Liu"<
> [e-mail]>
> Cc: "linda.dunbar"<[e-mail]>, "can"<[e-mail]>, "
> [e-mail]"<[e-mail]>
> I would put it a  little differently.  The application-centric approach is
> clearly valid.  It is clearly currently practiced.  the application folks
> have not, to my knowledge, asked for any improvements in the information
> they have.  If they do, we would have to work out what they need / want,
> etc.
> There is also a valid network-service centric approach in which the
> network offers a service for delivering the application traffic well.  That
> is the service that the CAN work enables.  Whether applications choose to
> use the application-centric approach, or the network-centric approach will
> likely depend upon whether we can build a network-centric approach that
> works, whether operators choose to offer it, and other similar issues.  It
> seems to me it is worth trying to build the technology so that the
> operators can decide if they want to offer it, and the applications can
> decide if they want to use it.
> The important evolution in the discussion was that the network-centric
> approach can (and by the charter we are discussing should) be built in such
> a way as to avoid burdening the network infrastructure.
>
> Yours,
> Joel
>
> On 1/28/2023 6:40 AM, Robert Raszuk wrote:
>
> Hello Peng,
> > So CAN won't impact every routers but just egress and ingress
>
>
> That's true. But here we are essentially talking about completely
> different directions/architectures and considering the selection on which
> one to take. Both are vastly different and pretty orthogonal to each other.
>
>
> *Option 1 - network centric -* the one you are suggesting -
>
>
> * Use anycast /32 or /128 as destination address
> * Enable reception and installation of multiple paths for each anycast
> address
> * Push tons of very dynamic data to each ingress router from behind egress
> routers **
> * Associate that dynamic data with specific active path or subset of paths
> of subject anycast addresses
> * Pre resolve in real time (continued FIB churn) all of the paths of
> anycast addresses in respect to load behind them  - and that must be done
> irrespective of any interest for that data
> * Make egress selection based on that state.
>
>
> ** - I realize that you will contest this and say that there is going to
> be a very small amount of relatively static data to start with. But I can
> rest assure you that even if you start wil small and static inputs this
> will grow fast as compute selection will require to accommodate new data
> points as we go along.
>
>
> *Option 2 - application centric - *
>
>
> * Do not use anycast
> * Do not put any of the dynamic state of the compute/content load/state to
> the network
> * When application is trying to resolve address of the compute/content
> cluster just be smart of what address is returned to it
> * No touch to the network - letting it do what it is good to do - take
> your packet and deliver it to the dst address in the packet
> * Load information is not broadcasted anywhere - can stay local and only
> the resolvers need to be aware of it
>
>
> Also note that while you could perhaps make option 1 work in your (say
> 5G) network for your service it does not sound like it would be
> applicable to access public clouds compute cluster based on the actual
> load in the same way over  the Internet.
>
>
> So bottom line is that while I have been working on network centric
> services for nearly 25 years now in this very case I do believe we should
> really focus on option 2 for addressing CAN's requirements.
>
> Kind regards,
> Robert
>
>
> On Sat, Jan 28, 2023 at 3:48 AM Peng Liu <[e-mail]>
> wrote:
>  Hi Robert,
>
>
> There might be OTT based solutions that don't involve ingress/egress
> routers . But some environments, like in our 5G edge network, OTT method
> is more expensive than a mechanism for egress routers to distribute the
> information to ingress routers so that path selection engines can consider
> both. CAN aims at the case where the operator wants to offer the
> selection service from its edge devices.
>
>
> In the charter, 'The assumed model for the CAN WG is an overlay network,
> where an ingress routing node makes a forwarding decision based on the
> metrics of interest, and then steers the traffic to an egress node that
> serves the selected service instance, for example using a tunnel.
> Architectures that require the underlay network to be service-aware are
> out of scope.'
>
> So CAN won't impact every routers but just egress and ingress, before the
> architecture, it is a little early to determine which protocol could be used.
> But for the directions, I think IETF is for building various tools. like
> one person can use  knife to peel an apple doesn’t mean peeler shouldn’t be
> invented.
>
>
> Regards,
> Peng
>
>  [e-mail]
>
>
>  *From:* Robert Raszuk <[e-mail]>
> *Date:* 2023-01-28 05:35
> *To:* Linda Dunbar <[e-mail]>
> *CC:* John Scudder <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Can] [Idr] Proposed CAN WG charter for discussion
> Hi Linda,
>
> But why do we need to do that within the underlay network vs Over The Top
> (OTT) way ?
>
> Why network needs to be at all involved in distribution of the load
> information if we could solve it at the application level and keep network
> lean and as much stateless as possible ? Simple mapping plane will work
> just fine for this resulting in OTT Compute Aware Load Balancer (for the
> lack of the better name).
>
> Why bring this "awareness" to BGP or IGP or even routers in general ?
>
> Isn't the draft https://www.ietf.org/id/draft-kjsun-lisp-dyncast-03.html
> a possible solution ?
>
> Many thx,
> R.
>
>
> On Fri, Jan 27, 2023 at 9:43 PM Linda Dunbar <[e-mail]>
> wrote:
> John,
>
> Oh, I guess I have over-thought of the "Architecture & framework".
> The proponents' wanting a mechanism for egress routers to distribute
> computing resources to ingress routers can be considered as one rough
> architecture.
>
> Thank you.
>
> Linda
>
> -----Original Message-----
> From: John Scudder <[e-mail]>
> Sent: Friday, January 27, 2023 12:06 PM
> To: Linda Dunbar <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Proposed CAN WG charter for discussion
>
> Hi Linda,
>
> I didn't mean to say that the architecture would have to be completed to
> the point of RFC publication before that step could be started! But of
> course, anyone studying the applicability of a mechanism, has to be
> thinking, "applicable for what purpose"? So I think that studying
> applicability presupposes that the person doing the study has an
> architecture in mind.
>
> Your summary seems about right, and I think it demonstrates that those in
> the side discussion *do* have at least a rough architecture in mind. My
> point is,
>
> a. It's important to write that rough architecture down, to make the
> assumptions transparent to all WG participants, and b. It's important that
> when listing work items, we do not lose sight of the fact that this is one
> work item.
>
> I don't see the bullet list as comprising a strictly ordered list of tasks
> that have to be completed in the order listed, I'm sure some will be worked
> on in parallel or even out of order.
>
> I hope that helps?
>
> -John
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>