Re: [alto] Secdir last call review of draft-ietf-alto-cost-mode-03

[mohamed.boucadair]

Hi Stephen,

Thank you for the review. 

I confirm. The part you quoted from Section 6.1.2 is still valid as is. 

Cheers,
Med

> -Message d'origine-
> De : Stephen Farrell via Datatracker 
> Envoyé : jeudi 19 mai 2022 14:48
> À : sec...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-mode@ietf.org; last-
> c...@ietf.org
> Objet : Secdir last call review of draft-ietf-alto-cost-mode-03
> 
> Reviewer: Stephen Farrell
> Review result: Ready
> 
> This document seems ready to me.
> 
> I did have one question - RFC7285 says that servers MUST support
> one of the numeric or ordinal cost-modes. It wasn't entirely clear
> to me whether it's intended that that remain the case, but I
> assume it is, so that e.g. it'd be invalid to have a server that
> only supports some new "foo" cost mode. If that's the case, then
> this draft is fine. If something else was intended then I guess a
> bit more text on that would be needed.
> 


_

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.

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

[alto] Secdir last call review of draft-ietf-alto-cost-mode-03

[Stephen Farrell via Datatracker]

Reviewer: Stephen Farrell
Review result: Ready

This document seems ready to me.

I did have one question - RFC7285 says that servers MUST support one of the
numeric or ordinal cost-modes. It wasn't entirely clear to me whether it's
intended that that remain the case, but I assume it is, so that e.g. it'd be
invalid to have a server that only supports some new "foo" cost mode. If that's
the case, then this draft is fine. If something else was intended then I guess
a bit more text on that would be needed.


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

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

[Qin Wu]

Hi, Kai:

发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2022年5月18日 19:05
收件人: Qin Wu 
抄送: Danny Lachos ; Jordi Ros Giralt 
; alto@ietf.org
主题: Re: RE: [alto] 5/3/2022 Meeting Minutes


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" mailto:bill...@huawei.com>>
Sent Time:2022-05-18 13:07:36 (Wednesday)
To: "Danny Lachos" mailto:dlac...@benocs.com>>, "Jordi Ros 
Giralt" mailto:j...@qti.qualcomm.com>>, 
"kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>, 
"alto@ietf.org" mailto: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 mailto:j...@qti.qualcomm.com>>; 
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.

[Qin Wu] Based on the approach and use case you describe, I feel you are 
discussing the second direction, i.e., use ALTO to feed information to a DNS 
server and allow DNS server change the order of DNS A records, return the 
results to the DNS client, what am I missing?

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

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

[Qin Wu]

Thanks Luis for quick response on behalf of ALTO design team, for others who 
want to evaluate CAN proposal, please also share your thoughts and inputs to 
this thread.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2022年5月18日 22:52
收件人: liupeng...@chinamobile.com; alto 
抄送: dyncast 
主题: Re: [alto] Fw: Re: [Dyncast] 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

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