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

[Joel Halpern <[e-mail]>]

My inclination would be to leave the analysis of the public cloud 
applicability to the working group.  Whether it is or is not applicable 
is not obvious.

Yours,

Joel

On 1/29/2023 6:40 PM, Linda Dunbar wrote:
>
> Robert,
>
> You said:
>
> /“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.” /
>
> I think that is a very good point. Making CAN applicable to access 
> public clouds might not be wise. Maybe we should add this point to the 
> CAN scope?
>
> My two cents,
>
> Linda
>
> *From:*Robert Raszuk <[e-mail]>
> *Sent:* Sunday, January 29, 2023 4:27 AM
> *To:* 王雪伟1 <[e-mail]>
> *Cc:* Joel Halpern <[e-mail]>; John Scudder 
> <jgs=[e-mail]>; Peng Liu 
> <[e-mail]>; Linda Dunbar 
> <[e-mail]>; can <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] [Can] Proposed CAN WG charter for discussion
>
> Dear 王雪伟1,
>
> > I also agree with network-service centric approach for it can
>
> > provide more fine-grainedtraffic 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-grainedtraffic 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]
>     <mailto:[e-mail]>>
>
>     Date:  Sun, Jan 29, 2023, 03:24
>
>     Subject:  Re: [Idr] [Can] Proposed CAN WG charter for discussion
>
>     To: "Robert Raszuk"<[e-mail] <mailto:[e-mail]>>,
>     "Peng Liu"<[e-mail]
>     <mailto:[e-mail]>>
>
>     Cc: "linda.dunbar"<[e-mail]
>     <mailto:[e-mail]>>, "can"<[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>"<[e-mail] <mailto:[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]
>         <mailto:[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] <mailto:[e-mail]>
>
>         *From:*Robert Raszuk <mailto:[e-mail]>
>
>         *Date:*2023-01-28 05:35
>
>         *To:*Linda Dunbar <mailto:[e-mail]>
>
>         *CC:*John Scudder <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
>         [e-mail] <mailto:[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
>         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-kjsun-lisp-dyncast-03.html&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4990594a7f714754920608db01e35b10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638105848227827515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jrtj0X8MvmS8KJRh4BYg%2BVhQP39SV%2FTn%2Fu6hYtr50h8%3D&reserved=0>
>         a possible solution ?
>
>         Many thx,
>
>         R.
>
>         On Fri, Jan 27, 2023 at 9:43 PM Linda Dunbar
>         <[e-mail]
>         <mailto:[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] <mailto:[e-mail]>>
>
>         Sent: Friday, January 27, 2023 12:06 PM
>
>         To: Linda Dunbar <[e-mail]
>         <mailto:[e-mail]>>
>
>         Cc: [e-mail] <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[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] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/idr
>         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4990594a7f714754920608db01e35b10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638105848227827515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1BZIWyKUl8YdgW4LK7ZhpQn%2F1uBjdUds5UATyywK8tI%3D&reserved=0>
>
>
>     _______________________________________________
>     Idr mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4990594a7f714754920608db01e35b10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638105848227983427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aNhQXnrkLNWT5BOsGngSn2oT20m%2B%2BFPOWSeAjJqxgK8%3D&reserved=0>
>