|Document||Type||Approved BOF request|
|Responsible leadership||John Scudder|
|Send notices to||(None)|
Name: Computing-Aware Networking (CAN)
Service providers are exploring edge computing to achieve better response times, control over data, and carbon energy savings by moving computing services to the edge of the network in 5G MEC (Multi-access Edge Computing), virtualized central offices, and other scenarios.
Providing services by sharing computing resources located at multiple edges is an emerging concept that is useful for computationally intensive tasks. Ideally, services would be balanced across computing resources using service-specific metrics instead of being simply dispatched in a static way (e.g., to the geographically closest edge), since that might cause unbalanced usage of computing resources at edges which could further degrade user experience and system utilization contrary to the objectives of edge computing. Besides, some applications have both critical demands of computing and network resource that needs joint optimization. We have named this kind of network with dynamic traffic steering considering both network resource status and computing resource status as “Computing-Aware Networking” (CAN).
The first Internet-Drafts on CAN (see list below) were posted in 2019 and led to a number of side meetings and a non-WG forming BoF (200+ participants) at IETF-113. Since then, there have been further meetings and email discussions to advance the work.
The purpose of this BoF is to:
1.Review the problem space and use cases for Computing-Aware Networking.
2.Present the progress in terms of resolution of issues raised and clarifications to the key Internet-Drafts.
3.Discuss the use cases and the applicability of existing solutions.
4.Discuss a draft charter for a proposed working group.
- Status: WG Forming
- Responsible AD: John Scudder
- BOF proponents: Peng Liu <firstname.lastname@example.org>, Luis Contreras <email@example.com>, Mohamed Boucadair <firstname.lastname@example.org>, Christian Jacquenet <email@example.com>, Markus Amend <Markus.Amend@telekom.de>, Kyoungjae Sun <firstname.lastname@example.org>, Younghan Kim <email@example.com>, Cheng Li <firstname.lastname@example.org>, Daniel Huang <email@example.com>, Changwang Lin <firstname.lastname@example.org>，Gyan Mishra <email@example.com>
- Suggested BOF chairs: Linda Dunbar <firstname.lastname@example.org>, Jeffrey Zhang <email@example.com>
- Number of people expected to attend: 100
- Length of session (1 or 2 hours): 1.5 hours
- Conflicts (whole Areas and/or WGs)
- Chair Conflicts: Depends on selection of chairs
- Technology Overlap: IDR, LSR
- Key Participant Conflict: TBD
Information for IAB/IESG
- Any protocols or practices that already exist in this space: there are proprietary protocols/solutions that consider both DC sites resources and/or network conditions (e.g. Cloud DC proprietary solutions, application load balancers). Besides, existing IETF routing protocols can be extended/combined to satisfy the requirements, such as Anycast, BGP. More analysis could be found at https://datatracker.ietf.org/doc/draft-liu-dyncast-gap-reqs/.
- Which (if any) modifications to existing protocols or practices are required: might be, e.g. BGP
- Which (if any) entirely new protocols or practices are required: to be discussed in the WG
- Open source projects (if any) implementing this work: might be, e.g. FRROUTING，METALLB
- Administrivia and agenda
- Overview of the problem space
- Use case/Gap analysis/Requirement
- Quick presentation of proposed charter (scope, work item, solution to be open)
- Charter discussion
Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.
- Mailing List: https://www.ietf.org/mailman/listinfo/dyncast
- Draft charter: https://github.com/CAN-IETF/CAN-BoF-ietf115
- Reference: https://github.com/CAN-IETF/CAN-BoF-ietf113
- Relevant drafts:
- Problem Statement and Use Cases:
- Gap Analysis and Requirements
- Potential Architecture
- Potential Solutions