Re: [alto] [Dyncast] Fw: Re: CAN BoF issues #1 #5 #6

[Linda Dunbar]

Luis has good points.
Maybe the Relationship to ALTO (Issue #5) should be explained this way?

ALTO can be seen as an alternative way of addressing the problem space of 
computing-aware networking from Application Layer. Since not all applications 
will query ALTO server(s), especially when UEs roaming among different cell 
sites (gNBs) triggering different network paths, the ALTO reply for 
applications/services before traffic delivery might not be optimal or valid 
after the handover.
CAN is a network layer solution, trying to solve the problem from on-path 
forwarding-based decisions and can adapt to different ingress routers caused by 
UEs roaming among different cell sites (gNBs & UPFs).  While as ALTO tries to 
solve the problem by exposing information that can be consumed by 
applications/services before traffic delivery. 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.

My two cents,

Linda

From: Dyncast  On Behalf Of LUIS MIGUEL CONTRERAS 
MURILLO
Sent: Wednesday, May 18, 2022 9:52 AM
To: liupeng...@chinamobile.com; alto 
Cc: dyncast 
Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6

Hi Peng,

In my view, ALTO can be seen as an alternative (maybe complementary) way of 
addressing the problem space of computing-aware networking. The CAN proposition 
at RTG tries to solve the problem from on-path forwarding-based decisions, 
while ALTO try to solve the problem by exposing information that can be 
consumed by applications/services before traffic delivery. 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.

For more detailed comments, please see my answers in-line

Bets regards

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de 
liupeng...@chinamobile.com
Enviado el: miércoles, 18 de mayo de 2022 15:46
Para: alto mailto:alto@ietf.org>>
CC: dyncast mailto:dync...@ietf.org>>
Asunto: [alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6

Hi ALTO WG,

There was a Computing-Aware Networking(CAN) BoF of RTG area in IETF 113, which 
is to steer the traffic among multiple edge sites considering both network and 
computing resource statues. The progress was also presented briefly in ALTO WG 
meeting.

In the BoF, some people cared about the relationship between CAN and ALTO. We 
collected this issue and got the response from the proponents, also would like 
to post the clarification to see if there are more comments from the WG. Thanks!

#5 What is the relation between CAN and ALTO? (issue 
#5)

ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status;
[Luis>>] I think that this is rather a matter of scalable design, than an 
actual limitation in the sense that different instances of ALTO server could be 
put if actually needed.
2) time taken for ingress routers to get the responses from the ALTO server 
upon flows arrival;
[Luis>>] Again I don't see this as an actual issue in the sense that 
applications could interrogate ALTO server before deciding what is the best 
path to follow. We can expect very quick interaction with ALTO to assist on the 
decision, that will be later on applied to all the packets in the flow (until 
further optimization could be required by the application). ALTO will have 
timely information from the network, so always offering fresh info for 
assisting applications.
3) ALTO server may not know the instantaneous congestion status of the network, 
all link bandwidths, all information about the actual routing and whether the 
candidate endpoint itself is overloaded according to RFC7971
[Luis>>] In this respect ALTO can integrate performance metric information as 
described in draft-ietf-alto-performance-metrics
CAN is to identify various measurements for service instances including the 
hosting environment, get them normalized together with network metrics for 
ingress nodes to choose the service instances.

Regards,
Peng
__

Re: [alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Peng,

In my view, ALTO can be seen as an alternative (maybe complementary) way of 
addressing the problem space of computing-aware networking. The CAN proposition 
at RTG tries to solve the problem from on-path forwarding-based decisions, 
while ALTO try to solve the problem by exposing information that can be 
consumed by applications/services before traffic delivery. 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.

For more detailed comments, please see my answers in-line

Bets regards

Luis

De: alto  En nombre de liupeng...@chinamobile.com
Enviado el: miércoles, 18 de mayo de 2022 15:46
Para: alto 
CC: dyncast 
Asunto: [alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6

Hi ALTO WG,

There was a Computing-Aware Networking(CAN) BoF of RTG area in IETF 113, which 
is to steer the traffic among multiple edge sites considering both network and 
computing resource statues. The progress was also presented briefly in ALTO WG 
meeting.

In the BoF, some people cared about the relationship between CAN and ALTO. We 
collected this issue and got the response from the proponents, also would like 
to post the clarification to see if there are more comments from the WG. Thanks!

#5 What is the relation between CAN and ALTO? (issue 
#5)

ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status;
[Luis>>] I think that this is rather a matter of scalable design, than an 
actual limitation in the sense that different instances of ALTO server could be 
put if actually needed.
2) time taken for ingress routers to get the responses from the ALTO server 
upon flows arrival;
[Luis>>] Again I don’t see this as an actual issue in the sense that 
applications could interrogate ALTO server before deciding what is the best 
path to follow. We can expect very quick interaction with ALTO to assist on the 
decision, that will be later on applied to all the packets in the flow (until 
further optimization could be required by the application). ALTO will have 
timely information from the network, so always offering fresh info for 
assisting applications.
3) ALTO server may not know the instantaneous congestion status of the network, 
all link bandwidths, all information about the actual routing and whether the 
candidate endpoint itself is overloaded according to RFC7971
[Luis>>] In this respect ALTO can integrate performance metric information as 
described in draft-ietf-alto-performance-metrics
CAN is to identify various measurements for service instances including the 
hosting environment, get them normalized together with network metrics for 
ingress nodes to choose the service instances.

Regards,
Peng

liupeng...@chinamobile.com

From: Linda Dunbar
Date: 2022-05-18 05:46
To: liupeng...@chinamobile.com; 
dyncast
CC: rtgwg
Subject: Re: [Dyncast] CAN BoF issues #1 #5 #6
Peng,

The resolution for Issue 2 “Relation to ALTO” can add more on why ALTO “can’t 
really help to the service request”. How about the following?

Relation to ALTO (issue 
#5)

ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status; 2) time taken for ingress routers 
to get the responses from the ALTO server upon flows arrival; 3) ALTO server 
may not know the instantaneous congestion status of the network, all link 
bandwidths, all information about the actual routing and whether the candidate 
endpoint itself is overloaded according to RFC7971
CAN is to identify various measurements for service ins

[alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6

[liupeng...@chinamobile.com]

Hi ALTO WG,

There was a Computing-Aware Networking(CAN) BoF of RTG area in IETF 113, which 
is to steer the traffic among multiple edge sites considering both network and 
computing resource statues. The progress was also presented briefly in ALTO WG 
meeting. 

In the BoF, some people cared about the relationship between CAN and ALTO. We 
collected this issue and got the response from the proponents, also would like 
to post the clarification to see if there are more comments from the WG. Thanks!

#5 What is the relation between CAN and ALTO? (issue #5)
 
ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status; 2) time taken for ingress routers 
to get the responses from the ALTO server upon flows arrival; 3) ALTO server 
may not know the instantaneous congestion status of the network, all link 
bandwidths, all information about the actual routing and whether the candidate 
endpoint itself is overloaded according to RFC7971
CAN is to identify various measurements for service instances including the 
hosting environment, get them normalized together with network metrics for 
ingress nodes to choose the service instances.  

Regards,
Peng


liupeng...@chinamobile.com
 
From: Linda Dunbar
Date: 2022-05-18 05:46
To: liupeng...@chinamobile.com; dyncast
CC: rtgwg
Subject: Re: [Dyncast] CAN BoF issues #1 #5 #6
Peng, 
 
The resolution for Issue 2 “Relation to ALTO” can add more on why ALTO “can’t 
really help to the service request”. How about the following? 
 
Relation to ALTO (issue #5)
 
ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status; 2) time taken for ingress routers 
to get the responses from the ALTO server upon flows arrival; 3) ALTO server 
may not know the instantaneous congestion status of the network, all link 
bandwidths, all information about the actual routing and whether the candidate 
endpoint itself is overloaded according to RFC7971
CAN is to identify various measurements for service instances including the 
hosting environment, get them normalized together with network metrics for 
ingress nodes to choose the service instances.  Almost like the reverse of the 
ALTO. 
 
My two cents, 
Linda 
 
From: Dyncast  On Behalf Of liupeng...@chinamobile.com
Sent: Monday, May 16, 2022 6:24 AM
To: dyncast 
Cc: rtgwg 
Subject: [Dyncast] CAN BoF issues #1 #5 #6
 
Dear All,
 
Based on the categories of the CAN BoF issues, here are the responses to the 
following issues #1 #5 #6, which clarifies the relationship to ITU-CNC, 
3GPP-UPF and ALTO. Any comments are welcome. 
 
We will post the responses to more issues involved in BoF for more comments 
(https://github.com/CAN-IETF/CAN-BoF-ietf113/issues).  You can also add your 
comments to any of them. Thanks!
 
1. What is ITU-CNC and the relationship with CAN #1
 
CNC focus on the vision, scenarios, requirements, architecture and network 
function enhancements for future mobile core network and the telecom fixed, 
mobile, satellite converged network, but not for internet or routing area. CAN 
Aims at computing and network resource optimization by steering traffic to 
appropriate computing resources considering not only routing metric but also 
computing resource metric and service affiliation.
 
2. Relation to ALTO #5
 
ALTO has the potential opportunity to help to the deployment of the application 
and computing resource but can't really help to the service request because the 
ALTO service may not know the instantaneous congestion status of the network, 
all link bandwidths, all information about the actual routing and whether the 
candidate endpoint itself is overloaded according to RFC7971. Moreover, Alto is 
an indirection-based method, contrasting with the on-path solution advocated by 
CAN. 
 
3. Relation to 3GPP UPF #6
 
The CAN dyncast work is to depend on the network device to steering traffic 
other than the UPF. Virtualized UPFs in 5G have a similar issue: multiple UPFs 
instances can serve a group of gNB nodes. Selecting the UPF instance not only 
needs UPF load condition but also need network conditions.
 
Regards,
Peng
 


liupeng...@chinamobile.com
 
From: Linda Dunbar
Date: 2022-05-11 06:11
To: dync...@ietf.org
Subject: [Dyncast] Categories of the CAN BoF issues
CAN BoF proponents:
 
Many tha

Re: [alto] 5/3/2022 Meeting Minutes

[kaigao]

Hi Qin, Danny and all,




Sorry I did not get the email from Danny and just saw this discussion. Please 
see my comments inline.




Best,

Kai



-Original Messages-
From:"Qin Wu" 
Sent Time:2022-05-18 13:07:36 (Wednesday)
To: "Danny Lachos" , "Jordi Ros Giralt" 
, "kai...@scu.edu.cn" , 
"alto@ietf.org" 
Cc:
Subject: RE: [alto] 5/3/2022 Meeting Minutes



Hi, Danny:

Interesting PoC, any more details about your PoC introduction. I am wondering 
what technique you are using for data correlation, how these correlated 
information are consumed by the application? I assume these steps do not 
require extension to Network Map or Cost Map.

 

-Qin

发件人: alto [mailto:alto-boun...@ietf.org] 代表 Danny Lachos
发送时间: 2022年5月10日 2:38
收件人: Jordi Ros Giralt ; kai...@scu.edu.cn; alto@ietf.org
主题: Re: [alto] ?==?utf-8?q? ?==?utf-8?q? 5/3/2022 Meeting Minutes

 

Hello Jordi, Kai, all

 

Thanks a lot for sharing,

I have a couple of quick comments/questions:

 

Regarding the OpenALTO meetings [0], I saw that Kai is currently working on 
integrate ALTO in DNS. If I do not wrong, it is supposed to use ALTO as a 
northbound interface to provide information about the domain name resolution to 
DNS clients, right?, if not, there is a chance to explain a little bit more 
about what is being done on ALTO/DNS?




There are two directions. One is to provide ALTO information through DNS and 
the other is to use ALTO to feed information to a DNS server. The first 
direction is definitely an interesting and potentially useful direction but we 
haven't got the man power to work on that. Right now we are using ALTO 
information to change the order of A records returned by a DNS server. The 
current proof-of-concept is to update the sort list option [1] based on ALTO 
cost map. Another approach in this direction is to change the preferences of A 
records of the same host name on the client side but we also haven't really 
started yet.





To put the integration into a context, you may refer to the footprint paper 
(NSDI'16). The idea is to control user traffic through DNS remapping. However, 
I'm looking more in the case where the application is not in the same 
administrative domain as the underlying network provider, and the ALTO maps are 
constructed based on my NAI'21 paper instead of from the ISP.





[1] http://www.ipamworldwide.com/ipam/sortlist.html


 

Here at Benocs, we are also working with DNS information that is correlated 
with network traffic flows to obtain a multi-dimensional traffic information. 
In fact, we are implementing a PoC environment for the development of practical 
use cases. This PoC is able to read DNS traffic, network traffic flows, BGP 
information and then making correlations (real-time or batch processing).

 

This sounds very interesting. Like Qin's comment, I would be very interested to 
hear more about the use cases and how you make the correlations.


In some point, could be interesting to find some kind of interception about 
what you/we are currently dealing in terms of technical and/or scientific 
challenges.

 

Certainly.


On 04.05.22 14:12, Jordi Ros Giralt wrote:

Thank you very much Jensen for taking meeting minutes yesterday. 

 

For those who could not attend our call yesterday (and for our bookkeeping), 
here you will find them: 
https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2022.md

 

Going forward, you will also find minutes for the OpenALTO meetings being held 
weekly too (Mon, Wed and Thu) here: 
https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-openalto-2022.md.
 As you know, everyone is invited to attend these other meetings that focus on 
the implementation of the Standard, see the meeting coordinates in this 
previous link for days and zoom link.

 

This action resolves ticket 
https://github.com/ietf-wg-alto/wg-materials/issues/23

 

Thanks,

Jordi on behalf of ALTO WG

  

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
-- 
Best regards,
 
Dr.-Ing. Danny Lachos
BENOCS GMBH
www.benocs.com
 

[0] 
https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-openalto-2022.md

 ___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto