Re: [Can] Polishing the charter text (stage 1)

[Linda Dunbar <[e-mail]>]

Adrian,

"Server" is a more commonly used term than "Computer" in Data Centers.  Multiple service instances can be instantiated on one Server.  Typically, there are tools monitoring "server utilization" which includes CPU, ports, links, memory utilization, etc.

Linda

From: Adrian Farrel <[e-mail]>
Sent: Sunday, February 12, 2023 2:00 PM
To: Linda Dunbar <[e-mail]>; 'Cheng Li' <c.l=[e-mail]>; [e-mail]; [e-mail]
Cc: 'JACQUENET Christian INNOV/NET' <[e-mail]>
Subject: RE: [Can] Polishing the charter text (stage 1)

Hi Linda,

I'm struggling here because there are clearly two different uses of the term "resources".

The main use is the storage, capacity, processing, power, blah, blah. That is what the metrics will cover.

I am trying to find a term for the "place" where the compute service is performed that justifies it being called a compute service. Maybe the term "computer" would be enough? It's not a term I generally like using.

Ah, "computing platforms" may be the thing.

Adrian

From: Can <[e-mail]<mailto:[e-mail]>> On Behalf Of Linda Dunbar
Sent: 10 February 2023 18:46
To: Cheng Li <c.l=[e-mail]<mailto:c.l=[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: JACQUENET Christian INNOV/NET <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Can] Polishing the charter text (stage 1)

Adrian,

The polished version looks good.
One minor issue:
Since the "Computing aware" can include all the relevant resources available at the site for the services (e.g. storage, capacity including server ports capacity, power, etc.), should we remove the "processors" from the first paragraph?

The services are provided on computing resources (processors) and are generically referred to as "compute services".

Agree with Cheng: 'from client to service instance' means 'from client to service site and then to a service instance'.

Linda
-----Original Message-----
From: Can <[e-mail]<mailto:[e-mail]>> On Behalf Of Cheng Li
Sent: Friday, February 10, 2023 3:05 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: JACQUENET Christian INNOV/NET <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Can] Polishing the charter text (stage 1)

Agree with Med about the
s/a service instance/a service site that host service instances.

Though I understand that 'from client to service instance' means 'from client to service site and then to a service instance', imaginable, and understandable.

BTW, the clean version looks good to me. I think the charter can clearly describe the problem that CAN would like to address, which can help IESG to understand our consensus.

Thank you for the modification!
Cheng


-----Original Message-----
From: Can [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, February 10, 2023 4:59 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: JACQUENET Christian INNOV/NET <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Can] Polishing the charter text (stage 1)

Hi Adrian, all,

Most of the changes look good. Please see inline some tweaks, fwiw.

Cheers,
Med

> -----Message d'origine-----
> De : Can <[e-mail]<mailto:[e-mail]>> De la part de Adrian Farrel Envoyé :
> vendredi 10 février 2023 08:48 À : [e-mail]<mailto:[e-mail]> Objet : [Can]
> Polishing the charter text (stage 1)
>
> Hi all,
>
> I have done a detailed read looking for points that might cause us to
> trip up further down the line. I've also gone through all of the
> comments I could find on the list.
>
> Please shout if you have any issues with these proposed changes.
> Please raise *new* proposed changes on a separate thread so we don't
> all go mad trying to track them!
>
> Cheers,
> Adrian
>
> ===
>
> 1. What is Computing-Aware Networking?
>
> As discussed in some previous threads, we all know what we mean, but
> we haven't actually said it in the charter text. We should be clear on
> this.
> How about:
>
> OLD
> Many modern service architectures create multiple service instances.
> These instances are often geographically distributed to multiple
> sites. The CAN (Computing-Aware Networking) working group
> (WG) is chartered to consider the problem of how the network edge can
> steer traffic between clients of a service and sites offering the
> service.
> NEW
> Many modern service architectures create multiple service instances.
> These instances are often geographically distributed to multiple
> sites. The services are provided on computing resources
> (processors) and are generically referred to as "compute services".
> The CAN (Computing- Aware Networking) working group
> (WG) is chartered to consider the problem of how the network edge can
> steer traffic between clients of a service and sites offering the
> service.
> END
>

[Med] I suggest to delete the "modern" thing from the text. What is actually new is the dynamicity in steering the traffic/service instance selection, not the distribution of the service instances.

> 2. Capacity versus capability
>
> Referencing a comment from Med, we should..
>
> OLD
> Since, for some services (for example, VR/AR, intelligent
> transportation), the performance experienced by clients will depend on
> both network metrics such as bandwidth and latency, and compute
> metrics such as processing and storage capacity NEW Since, for some
> services (for example, VR/AR, intelligent transportation), the
> performance experienced by clients will depend on both network metrics
> such as bandwidth and latency, and compute metrics such as processing
> and storage capabilities and capacity END
>

[Med] Thanks.

> 3. Optimization functions are out of scope
>
> I think we should agree that the working group is not going to develop
> of specify optimization functions. These are not needed for
> interoperability and can be left as value add for operators or
> developers. The text currently
> has:
>
> OLD
> Although the specific optimization function will likely differ between
> services, there is a need for a general framework for the distribution
> of compute and network metrics and transport of traffic from client
> edge to service instance.
> END
>
> In fact, the optimization function will differ not just between
> services, but between implementations and deployments. That is, it is
> entirely up to an operator how (or if!) they choose to optimize the
> delivery of a service within their network. So I would
> suggest:
>
> NEW
> Although the specific optimization function will likely differ between
> services, implementations, and deployments, there is a need for a
> general framework for the distribution of compute and network metrics
> and transport of traffic from client edge to service instance.
> END

[Med] I suggest the following to be consistent with the first para:

s/client edge/network edge or s/client edge/client-facing network edge

s/service instance/service site

>
> 4. As previously noted:
>
> OLD
> Specific characteristics
> that may distinguish CAN from other work include the desire to
> integrate both network and compute conditions in the optimization
> function, and the desire to operate the function on nodes within the
> service provider's network, logically separated from service
> operation.
> END
>
> s/the function/that function/
> (Makes it clear that it is the optimization function that is operated
> on nodes withing the service provider's network.)
>
> 5. Ingress and egress
>
> These are used a little casually in:
>
> OLD
> The assumed model for the CAN WG is an overlay network, where an
> ingress node makes a 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.
> END
>
> Of course, in the context of a tunnel, the term "egress" is great.
> Also in the case where the service function is accessed through a
> network edge. But, I think those are both only examples, and the scope
> includes placing the service node within the network. So I would like
> to replace "ingress node"
> with "client edge node", and "egress node" with "service instance"
> dropping "that serves the selected service instance" (both to match
> previous usage).
> I believe this is flexible enough to allow all possible solution
> architectures, but does not confuse the terminology. This leaves:
>
> NEW
> The assumed model for the CAN WG is an overlay network, where a client
> edge node makes a decision based on the metrics of interest, and then
> steers the traffic to a service instance, for example using a tunnel.
> Architectures that require the underlay network to be service-aware
> are out of scope.
> END
>
> Note that an alternative substitute for "egress node", also already
> used in the text, is "site offering the service".
>

[Med] I would change "client edge node" to whatever term agreed in the previous para. See the previous comment.

Also, I'm afraid that the new wording can be interpreted as if the edge nodes pick has to pick the exact instance and disallow the scheme where it only points to a service entry point in a site (that will then make a finer selection). I have a preference for a more generic wording:

s/a service instance/a service site that host service instances


> 6. Nit
>
> The bullet hierarchy is broken.
>
> 7. Nits
>
> s/Internet Drafts/Internet-Drafts/
> s/ and not necessarily/, not necessarily/ s/as an RFC:/as RFCs:/ s/the
> need for considering/the need to consider/
>
> 8. There is some clumsy text. I suggest...
>
> OLD
> o  Use cases for using the network and computing resource status to
> benefit
>     the steering of traffic from applications that have a critical SLA
> that
>     would require the integrated considerations of network-path
> conditions
>     and computing resources.
> NEW
> o  Use cases for steering traffic from applications that have critical
> SLAs
>     that would benefit from the integrated consideration of network
> and
>     computing resource status.
> END
>
> 9. Nit
>
> s/scalability and security aspects/scalability, and security aspects/
>
> 10. Nits
>
> s/gaps of existing tools/gaps in existing tools/ s/requirements
> mechanisms and suitability/requirements, mechanisms, and suitability/
>
> 11. Nit
>
> Consistent capitalisation of documents in the Milestones section
>
> 12. Nit
>
> Don't use ampersand when "and" will do.
>
> 13. Centralized versus de-centralized
>
> Cong Li suggested that "the architecture of CAN should not be limited
> to centralized way or distributed way now." Checking the current text,
> I think there is nothing in there that pushes this in either
> direction, and I don't think it is necessary to mention it in the
> charter. So, no change proposed.
>
> --
> Can mailing list
> [e-mail]<mailto:[e-mail]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C0675ffd9d4d5464c982008db0d33b7df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638118288019560295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=elxI1zpLHx9VDD3yB6v2PAWjodRSuxX55BuV5dAaDJc%3D&reserved=0>.
> ietf.org%2Fmailman%2Flistinfo%2Fcan&data=05%7C01%7Clinda.dunbar%40futu
> rewei.com%7C9dc6bad7944d433f789c08db0b45ece5%7C0fee8ff2a3b240189c753a1
> d5591fedc%7C1%7C0%7C638116167184783853%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=xgZgByDcwHUX%2Bjo8CsDpdLTqRpi9ADZ5x4jgHXdcupg%3D&reserved=
> 0

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--
Can mailing list
[e-mail]<mailto:[e-mail]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcan&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C9dc6bad7944d433f789c08db0b45ece5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116167184940075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HAYEO9Ax7dag5mmWo3YXh7UuhUAXg3PKLw5XGd6R%2Fak%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcan&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C0675ffd9d4d5464c982008db0d33b7df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638118288019560295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IGT7TUTKcSPzFzMGHmxi9F9J9r3jQ9saQlgEQoIHRTw%3D&reserved=0>

--
Can mailing list
[e-mail]<mailto:[e-mail]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcan&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C9dc6bad7944d433f789c08db0b45ece5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116167184940075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HAYEO9Ax7dag5mmWo3YXh7UuhUAXg3PKLw5XGd6R%2Fak%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcan&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C0675ffd9d4d5464c982008db0d33b7df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638118288019560295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IGT7TUTKcSPzFzMGHmxi9F9J9r3jQ9saQlgEQoIHRTw%3D&reserved=0>