If by "on-path" we mean an edge device using higher level information to
tunnel packets to the intended egress edge, then I understand what is
beign asked.
However, if this is read in any way to mean that the edge computing
properties are to be injected into underlay routing burdening all the
routers in the domain, then no, I think the description is wrong and
needs to be clarified to rule that out of scope.
Yours,
Joel
On 5/31/2022 7:19 AM, Dirk Trossen wrote:
Hi Zhengyuan,
Thanks, interesting separation of the issues, i.e., deployment,
discovery and traffic steering (or maybe runtime resolution, if you
will).
So yes, this is what it boils down to and I see CAN as advocating an
on-path service instance selection architecture, unlike, e.g.,
DNS-based systems (including GSLB), which make that instance selection
off-path.
I do agree that clarifying this in the existing drafts, e.g., the arch
draft but also when positioning against existing (e.g., off-path)
solutions, would be good.
Best,
Dirk
*From:*Dyncast [mailto:[email protected]] *On Behalf Of
*[email protected]
*Sent:* 31 May 2022 13:17
*To:* dyncast <[email protected]>
*Cc:* rtgwg <[email protected]>
*Subject:* [Dyncast] 答复: CAN BoF issues #19 #21 #23
Hi All,
In my understanding, the whole story includes service deployment,
service discovery and service traffic steering. CAN assumes the
services have been deployed and discovered in multi-edge sites, aiming
at the traffic steering. So CAN’s scope is clear, and I think it is
better to add some explanations in the existing drafts.
Best,
Zhengyuan
*发件人**:*[email protected] <[email protected]>
*日期**:*星期二, 2022年5月31日上午12:00
*收件人**:*dyncast <[email protected]>
*抄送**:*rtgwg <[email protected]>, Tony Li <[email protected]>, resnick
<[email protected]>
*主题**:*CAN BoF issues #19 #21 #23
Dear All,
Based on the categories of the CAN BoF issues, here are the responses
to the following issues #19 #21 #23, which are related to the service
discovery and the potential cooperation with application layer. Any
comments are welcome. Thanks!
#19 For each application there might be a overlay plane, because the
resources/metric is specific to the plane. #19
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/19>
Part of the work in CAN is to identify methods to describe metrics as
well as decision making mechanisms in a manner that those may be
utilized by many applications, while also minimizing the exposed
semantics to the CAN provider. Furthermore, CAN may allow to act on
categories of services rather than individual services themselves,
where the metrics and decision making may be applied across the
specific category.
#21 The CAN problem is not striked as a routing problem, it's all
service discovery that can be done in higher layers. #21
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/21>
Indeed, CAN be described as a service instance selection problem,
where said instance is being chosen as one from possibly many while
forwarding the packet from the client to the chosen instance. With
this, it can be described as an on-path solution, while current
solutions can be categorized as off-path solutions, often performing a
dedicated service discovery/resolution step before engaging in direct
communication between client and the discovered/resolved instance.
This dedicated discovery/resolution step adds latency as well as
additional complexity to the overall communication, which may cause
issues in scenarios with dynamic re-assignment of clients to service
instance.
#23 It needs application information too, so it can't just make a
decision at the network layer.
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/23>#23
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/23>
It is the scope of proposed work what information and which semantic
needs exposure across business boundaries (e.g., from application to
network provider) in order to make suitable decision. Opague decision
making is possible through conveying utility functions operating on
numerals only.
There may be deployments in which network and service entities may be
owned by the same entity(e.g operators), thereby simplifying the
crossing of information, such as computing load, from the computing to
the networking infrastructure and vice versa.
PS: The issues #1
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/1> #5
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/5> #6
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/6> #9
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/9> #20
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/20> #25
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/25> were updated
according to the discussion, and will be still opened for a while to
see if there are any more comments.
You can also add your comments to any of
them(https://github.com/CAN-IETF/CAN-BoF-ietf113/issues).
Regards,
Peng
------------------------------------------------------------------------
[email protected]
*From:*Linda Dunbar <mailto:[email protected]>
*Date:* 2022-05-11 06:11
*To:*[email protected] <mailto:[email protected]>
*Subject:* [Dyncast] Categories of the CAN BoF issues
CAN BoF proponents:
Many thanks for creating the CAN BoF issues tracking in the
Github:
https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/created_by/CAN-IETF?page=1&q=is%3Aopen+is%3Aissue+author%3ACAN-IETF
<https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/created_by/CAN-IETF?page=1&q=is%3Aopen+is%3Aissue+author%3ACAN-IETF>
I went through the issues captured in the Github and characterized
them into groups. Some issues can be lumped together for the
discussion. There are quite a few issues related to the
requirements, which need to be clarified.
Best Regards, Linda
*Issues associated with Applications vs. Underlay networks:*
·Consider not to load underlay network with application details. #35
·We have multiple upper layer application. Do we have additional
needs for routing(e.g. WG?) or we are using those applications and
won't need such new WG? #30
·It needs application information too, so it can't just make a
decision at the network layer. #23
·This is not striked as a routing problem; it's all service
discovery that can be done in higher layers. #21
·*3GPP and URSP solve this based on UPF selection. It uses both
endpoint + application. #20*
·One overlay plane per application. Resources/metric specific to
the plane. #19
·How does the application layer or the transport layer learn the
network status to steering traffic? #16
*Need more clear requirements for CAN (*to be addressed by
draft-liu-dyncast-ps-usecases*):*
·Need to understand if three are requirement to avoid extra
messages or 1ms of latency #36
·Regarding the flow affinity, is it from network perspective or
from application/computation perspective? #33
·How to effectively compute paths? Shall we put CPUs into account? #32
·*What happens when the user moves? If so we also need to move
application context. #25*
·It can only move the services around as fast as it can update the
routing plane. which comes back to the point about service
discovery (waiting for convergence/distribution as opposed to just
updating the SD server) #24
·Whether the interests of the organization deploying the
application and the organization providing the network
connectivity are aligned. Google doesn't worry about this because
they are both. #17
oThe question is more what the scope and semantic of information
is that will need to cross organizational boundaries. This needs
further study, in particular when assuming stakeholder division
between service and network provider.
·It seems impossible to satisfy that requirement simultaneously
with the latency requirement. #15
·It wasn't clear that how hard of a requirement session
persistence is. #13
oA session usually creates ephemeral state. If execution changes
from one (e.g., virtualized) service instance to another,
state/context needs transfer to another. Such required transfer of
state/context makes it desirable to have session persistence (or
instance affinity) as the default, removing the need for explicit
context transfer, while also supporting an explicit state/context
transfer (e.g., when metrics change significantly).
·*Should it select UPF based on the application? Steering is done
per user? or per application? #9*
·This seems to assume conventional non-distributed applications
just running at the edge. what about modern frameworks like
Sapphire? and Ray? #7
oIt would be good to understand the multi-site requirements of
such framework, which I have understood to mainly run in single DCs.
·*Relation to 3GPP UPF #6*
·*Relation to ALTO #5*
·Do the mobility issues and associated protocols are also in
scope? There are scenarios where routing alone would not be
sufficient. #4
·What is the position in the edge location regarding to UPF? #3
·Is there some sort of authorization model so that an edge can
indicate whether or not it will provide compute services? #2
·*What is CNC and the relationship with CAN #1*
*Measurement of the Computing Resources*(to be addressed by
draft-du-computing-resource-representation):
·It is hard to use existing work to measure the computation, but
we can optimize the latency through the performance monitoring. We
have performance/measurement matrix over there. #34
·Clarifications on the computing resource, its requirements and
characteristics would be helpful. #27
·Each application may have a different definition of "resources"
these then have to be boiled down into a single topology Network
Aware Computing (NAC! :) does scale #14
·Is computing resource measurable? #10
oIt is, and how to use the measurement would be solution related.
See IFIP Networking 2022 paper on how to simply expose “computing
capability” and achieve better steering with such simple measure.
·Why compute resource is different with other resources? #8
·
*Load Balance based solutions:*
·The point is that we need a standardized LB protocol #18
·The LB as part of the application itself is superior (part of the
distributed application itself is to obtain and keep updating the
"best" unicast location to use). #22
·If there is anything missing from current lbs that would prevent
their use as-is? other than there is for market reasons no interop
standard between different lbs? #12
·For the load balance, should it learn the network’s status? #11
·
*Dyncast based Solution issues:*
·For Dyncast, when the time is short, is it possible for the
router to decide the routing? It is too fast. #31
·Is dyncast proposed to encapsulate? #29
·Will CAN dyncast impact each and every router? How to avoid
loops? #28
·What's the assumed scale of a D-router? 10 ^ 6 sessions? 100^ 8?
What's the assumed update rate? !Gb? 1Tb? #26
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
