What is the relation between CAN and ALTO?

[CAN-IETF]

CAN is a network layer solution, performing on-path service instance selection decisions with the possibility to adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). ALTO solves the problem of service instance selection as an off-path solution, which can be seen as an alternative way of addressing the problem space of CAN at the Application Layer. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact.

Key here is the signaling latency and signaling load that the service instance selection will incur, both in on- as well as off-path solution. This is turn may impact the frequency with which applications will query ALTO server(s), especially when UEs are roaming among different cell sites (gNBs) triggering different network paths. As a result, off-path systems, e.g., ALTO, replies for applications/services before traffic delivery might not be optimal or valid after the handover. So, more details are needed of ALTO including some extension to support multi-deployment, quick interaction, integrate more performance metric information.

So, the differences between CAN and ALTO WG are:
ALTO is by inquiry and response mechanism, while as CAN is using on-Path plug-in (or components) for instance/site selections. The on-Path plug-in for instance/site selections require routing control messages for advertising path & destination conditions. The “Routing Control Messages” advertisement should belong to Routing Area, instead of Transport area.
Most likely the clients to ALTO servers are the end hosts who send query to the ALTO servers for the network conditions before sending the first packet, while as CAN plug-in for instance/site selection are on the ingress routers which receive packets continuously (i.e. without waiting period).
ALTO is not suitable for the Ingress routers which receive packets from many different clients continuously because it is very expensive and costly for the ingress routers to cache incoming packets while sending the inquiry ALTO servers to getting the response.

[muzixing]

we also describe the difference of CAN/dyncast and ALTO in the draft: https://datatracker.ietf.org/doc/html/draft-liu-dyncast-gap-reqs-00#section-3.3

[muzixing]

After discussion in mailing list, IETF meetings with people interested in CAN and ALTO, we get the conclusion: CAN aims to provide a possible on-path solution for efficiently steering traffic to one of possible many service instances. The on-path solution requires to make the decision on the ingress node of the network based on network and other metrics. These kind of metrics may be distributed through extensions to routing protocols. ALTO is by inquiry and response, i.e., off-path, mechanism, which is different from the on-path approach proposed in CAN.

The differences between CAN and ALTO are:
• ALTO is by inquiry and response, i.e., off-path, mechanism, while as CAN is using an on-path mechanism to steer the traffic to one of possible many service instances by mapping a service identifier space onto the existing network locator space for service instance selections. The on-path mapping of identifier spaces is foreseen to be done below the transport layer for transparency reasons, thus requiring the placement of this work in the routing area. Furthermore, decision criteria, i.e., metrics, may be distributed through extensions to existing or through novel routing protocols, thus additionally positioning this work as a routing area work.
• Most likely the clients to ALTO servers are the end hosts who send query to the ALTO servers for the network conditions before sending the first packet, while in CAN the ingress routers perform a runtime mapping of service identified packets onto locator-destined ones..
• Performing an ALTO-like solution on the direct path is not suitable because its request/reply protocol would lead to higher costs and latency.