Subject: Re: [alto] ALTO Draft ReCharter WG review

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 1 Mar 2021 18:36:16 -0500

Dear Peng,

Thank you so much for the feedback. Please see below.

On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 <[email-masked]> wrote:

> Hi WG,
>
>
> Here are some considerations of recharter:
>
> I believe that the multi domain problem is worthy of attention.
>

It is good info.

> At present, operators also research in it, which may involve guaranteeing
> end-to-end network service in the future, such as delay, bandwidth, etc.
> There are some researches on cross domain deterministic network in the
> industry, which need some support from management and control plane.
>

 Do you want to share some pointers?

Who is the provider of Alto service is related to the deployment and
> cooperation mode. It may be difficult for operators to give too much
> detailed network information now. If the Alto service belongs to the
> operator, it may be used to help manage its own network. If Alto service
> belong to non operators, I think the issue of how to cooperate needs
> further discussion.
>
>
> It looks that you want to consider both modes: multidomains but single
operator (i.e., intra-cooperation) and multidomains and multiple operators.
Regardless, I agree that it is important for the work to clarify on the
privacy requirements.

Richard

> Regards,
>
> Peng
>
> Peng Liu | 刘鹏
> China Mobile | 移动研究院
> mobile phone：13810146105
> email: * [email-masked] <[email-masked]>*
>
>
> 发件人: Qin Wu <[email-masked]>
> 时间: 2021/02/22(星期一)21:45
> 收件人: IETF ALTO <[email-masked]>;
> 抄送人: alto-chairs <[email-masked]>;alto-ads <[email-masked]>;
> 主题: [alto] ALTO Draft ReCharter WG review
>
> Hi, :
>
> We have requested one hour session for ALTO WG meeting in the upcoming
> IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
>
> The goal is to boil down ALTO recharter and have consensus on charter
> contents in IETF 110.
>
> To get this goal, an updated inline draft charter text for ALTO has just
> been posted to this list,
>
> This charter has received a couple of rounds of informal review from WG members, chairs and our Ads from brief to deep thorough, 5 new chartered items have been listed.
>
> We would like to solicit feedback on these new chartered items and your
> use case, deployment, idea corresponding to these new chartered items.
>
> Sharing your past deployment story will also be appreciated.
>
>
>
>
> ============================================================================================
>
> The ALTO working group was established in 2008 to devise a
> request/response protocol to allow a host to benefit from a server that is
> more cognizant of the network infrastructure than the host is.
>
>
>
> The working group has developed an HTTP-based protocol and recent work has
> reported large-scale deployment of ALTO based solutions supporting
> applications such as content distribution networks (CDN).
>
>
>
> ALTO is now proposed as a component for cloud-based interactive
> applications, large-scale data analytics, multi-cloud SD-WAN deployment,
> and distributed
>
> computing. In all these cases, exposing network information such as
> abstract topologies and network function deployment location helps
> applications.
>
>
>
> To support these emerging uses, extensions are needed, and additional
> functional and architectural features need to be considered as follows:
>
>
>
> o Protocol extensions to support a richer and extensible set of policy
> attributes in ALTO information update request and response. Such policy
> attributes may indicate information dependency (e.g., ALTO path-cost/QoS
> properties with dependency on real-time network  indications), optimization
> criteria (e.g., lowest latency/throughput network performance objective),
> and constraints (e.g., relaxation bound of optimization criteria, domain or
> network node to be traversed, diversity and redundancy of paths).
>
>
>
> o Protocol extensions for facilitating operational automation tasks and
> improving transport efficiency. In particular, extensions to provide
> "pub/sub" mechanisms to allow the client to request and receive a diverse
> types (such as event-triggered/sporadic, continuous), continuous,
> customized feed of publisher-generated information. Efforts developed in
> other working groups such as MQTT Publish / Subscribe Architecture, WebSub,
> Subscription to YANG Notifications will be considered, and issues such as
> scalability (e.g., using unicast or broadcast/multicast, and periodicity of
> object updates) should be considered.
>
>
>
> o The working group will investigate the configuration, management, and
> operation of ALTO systems and may develop suitable data models.
>
>
>
> o Extensions to ALTO services to support multi-domain settings. ALTO is
> currently specified for a single ALTO server in a single administrative
> domain, but a network may consist of
>
> multiple domains and the potential information sources may not be limited
> to a certain domain. The working group will investigate extending the ALTO
> framework to (1) specify multi-ALTO-server protocol flow and usage
> guidelines when an ALTO service involves network paths spanning multiple
> domains with multiple ALTO servers, and (2) extend or introduce ALTO
>
> services allowing east-west interfaces for multiple ALTO server
> integration and collaboration. The specifications and extensions should use
> existing services whenever possible. The specifications and extensions
> should consider realistic complexities including incremental deployment,
> dynamicity, and security issues such as access control, authorization
> (e.g., an ALTO server provides information for a network that the server
> has no authorization), and privacy protection in multi-domain settings.
>
>
>
> o The working group will update RFC 7971 to provide operational
> considerations for recent protocol extensions (e.g., cost calendar, unified
> properties, and path vector) and new extensions that the WG develops. New
> considerations will include decisions about the set of information
> resources (e.g., what metrics to use), notification of changes either in
> proactive or reactive mode (e.g., pull the backend, or trigger just-in-time
> measurements), aggregation/processing of the collected information  (e.g.,
> compute information and network information )according to the clients’
> requests, and integration with new transport mechanisms (e.g., HTTP/2 and
> HTTP/3).
>
>
>
> When the WG considers standardizing information that the ALTO server could
> provide, the following criteria are important
>
> to ensure real feasibility:
>
>
>
> - Can the ALTO server realistically provide (measure or derive) that
> information?
>
>
>
> - Is it information that the ALTO client cannot find easily some other way?
>
>
>
> - Is the distribution of the information allowed by the operator of the
> network? Does the exposure of the information introduce privacy and
> information leakage concerns?
>
>
>
> Issues related to the specific content exchanged in systems that make use
> of ALTO are excluded from the WG's scope, as is the issue of dealing with
> enforcing the legality of the content. The WG will also not propose
> standards on how congestion is signaled, remediated, or avoided.
>
>
>
> -Qin Wu (on behalf of chairs)
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: 刘鹏<[email-masked]>
Date: 02 Mar 2021 11:40:32 +0800

Hi Qin,

Thanks you. I still have some questions, please see my reply inline below.

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  [email-masked]

 

Hi WG,

I believe that the multi domain problem is worthy of attention. At present, operators also research in it, which may involve guaranteeing  end-to-end network service in the future, such as delay, bandwidth, etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane. 

[Qin]: thanks for sharing your use case, I think we may have many multi-domain applications.  Multiple domain setting is not only referred to multiple administrative domains belonging to the same operator but also referred to cross operator domains.

[Peng]: Yes, we can easily find the usecase of cross operators domains such as home broadband. 

Detnet can be a good use case for muit-domain setting, we may also consider many other  use cases such as traffic from source to destination spanning across multiple administrative domain, the computing and storage are distributed in different administrative domain

[Peng]: DetNet WG only solves the problem of single domain, because multi domain brings much more challenge to the deterministic latency guarantee. It may be difficult to implement strict multi domain deterministic latency guarantee now, but we may gradually optimize it.  

Which require resource discovery or multi domain SFC case. 

As stipulated by RFC7971, there is the network consisting of multiple domains and in many cases it is not possible to collect information across network borders.  This issue can be addressed by deploying ALTO server in each domain with hierarchy design or mesh design, and allow server to server communication. 

In addition, we need to consider multi domain connectivity discovery, multi domain service discovery.

[Peng]: I agree that it is difficult 'to collect information across network borders', and can you explain more about the "hierarchy design or mesh design"?  

     For the 'multi domain connectivity discovery, multi domain service discovery', is there any usecase or requirements can be found now?

Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much  detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion. 

[Qin]:I think one good use case we have is MOWIE use case, i.e., adjust the bitrate to  improve Cloud gaming QoE experience based on abstract network information to be exposed. For this use case, we can see a good collaboration between OTT provider and network operation, Probably they sign agreement for the mutual benefits reason. Also network  operator will provide aggregate and abstract network information and expose very few information to the client, this is what ALTO is designed for. 

The proposed work items related to MOWIE, feel free to review and evaluate it'

[Peng]: Thanks. I talked to Gang about MOWIE before.  It involves some new cooperation modes, which are worthy of further discussion and exploration in details. 

o Protocol extensions to support a richer and extensible set of policy attributes in ALTO  information update request and response. Such policy attributes may indicate information dependency (e.g., ALTO path-cost/QoS properties with dependency on real-time network  indications), optimization criteria (e.g., lowest latency/throughput network performance  objective), and constraints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed, diversity and redundancy of paths). 

o Protocol extensions for facilitating operational automation tasks and improving transport  efficiency. In particular, extensions to provide "pub/sub" mechanisms to allow the client to request and receive a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information. Efforts developed  in other working groups such as MQTT Publish / Subscribe Architecture, WebSub, Subscription to YANG Notifications will be considered, and issues such as scalability (e.g., using unicast or broadcast/multicast, and periodicity of object updates) should be considered.  

” 

Thanks! 

Regards, 

Peng  

 

Peng Liu | 刘鹏  

China Mobile | 移动研究院  

mobile phone：13810146105  

email:  [email-masked]    

 

发件人: Qin Wu  

时间: 2021/02/22(星期一)21:45  

收件人: IETF ALTO;  

抄送人: alto-chairs;alto-ads;  

 Hi, : 

 We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC).  

 The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110. 

 To get this goal, an updated inline draft charter text for ALTO has just been posted to this list,  

 We would like to solicit feedback on these new chartered items and your use case, deployment, idea corresponding to these new chartered items. 

The ALTO working group was established in 2008 to devise a request/response protocol to  allow a host to benefit from a server that is more cognizant of the network infrastructure than the host is.  

The working group has developed an HTTP-based protocol and recent work has reported large-scale  deployment of ALTO based solutions supporting applications such as content distribution networks (CDN).  

ALTO is now proposed as a component for cloud-based interactive applications, large-scale  data analytics, multi-cloud SD-WAN deployment, and distributed  

computing. In all these cases, exposing network information such as abstract topologies  and network function deployment location helps applications.  

To support these emerging uses, extensions are needed, and additional functional and architectural  features need to be considered as follows: 

o Protocol extensions to support a richer and extensible set of policy attributes in ALTO  information update request and response. Such policy attributes may indicate information dependency (e.g., ALTO path-cost/QoS properties with dependency on real-time network  indications), optimization criteria (e.g., lowest latency/throughput network performance  objective), and constraints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed, diversity and redundancy of paths).  

o Protocol extensions for facilitating operational automation tasks and improving transport  efficiency. In particular, extensions to provide "pub/sub" mechanisms to allow the client to request and receive a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information. Efforts developed  in other working groups such as MQTT Publish / Subscribe Architecture, WebSub, Subscription to YANG Notifications will be considered, and issues such as scalability (e.g., using unicast or broadcast/multicast, and periodicity of object updates) should be considered.  

o The working group will investigate the configuration, management, and operation of ALTO  systems and may develop suitable data models. 

o Extensions to ALTO services to support multi-domain settings. ALTO is currently specified  for a single ALTO server in a single administrative domain, but a network may consist of  

multiple domains and the potential information sources may not be limited to a certain  domain. The working group will investigate extending the ALTO framework to (1) specify multi-ALTO-server protocol flow and usage guidelines when an ALTO service involves network paths spanning multiple domains with multiple ALTO servers, and (2) extend or  introduce ALTO  

services allowing east-west interfaces for multiple ALTO server integration and collaboration.  The specifications and extensions should use existing services whenever possible. The specifications and extensions should consider realistic complexities including incremental deployment, dynamicity, and security issues such as access control, authorization  (e.g., an ALTO server provides information for a network that the server has no authorization), and privacy protection in multi-domain settings. 

o The working group will update RFC 7971 to provide operational considerations for recent  protocol extensions (e.g., cost calendar, unified properties, and path vector) and new extensions that the WG develops. New considerations will include decisions about the set of information resources (e.g., what metrics to use), notification of changes either  in proactive or reactive mode (e.g., pull the backend, or trigger just-in-time measurements), aggregation/processing of the collected information  (e.g., compute information and network information )according to the clients’ requests, and integration with  new transport mechanisms (e.g., HTTP/2 and HTTP/3). 

When the WG considers standardizing information that the ALTO server could provide, the  following criteria are important  

- Can the ALTO server realistically provide (measure or derive) that information? 

- Is the distribution of the information allowed by the operator of the network? Does  the exposure of the information introduce privacy and information leakage concerns? 

Issues related to the specific content exchanged in systems that make use of ALTO are  excluded from the WG's scope, as is the issue of dealing with  enforcing the legality of the content. The WG will also not propose standards on how congestion is signaled, remediated, or avoided.

---

From: Qin Wu <[email-masked]>
Date: Wed, 3 Mar 2021 09:14:14 +0000

Hi, Peng:
发件人: 刘鹏 [mailto:[email-masked]]
发送时间: 2021年3月2日 11:41
收件人: Qin Wu <[email-masked]>
抄送: IETF ALTO <[email-masked]>
主题: Re: RE: [alto] ALTO Draft ReCharter WG review

Hi Qin,

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105
email:  [email-masked]<mailto:[email-masked]>

Hi WG,

[Qin-1]Yes, you are right, reading Detnet charter,  its scope did focuses on single administrative control domain or within a closed group of administrative control domain. I believe RAW WG also focuses on single domain issue.

[Qin-1]:In hierarchy design, ALTO servers in the domain partitions (e.g., each local domain) gather local information and send it to centralized ALTO server.

The mesh design, is more like peer to peer pattern design, ALTO servers may be set up in each domain independently, and gathering the network information from other connected adjacent domains.

Multi-domain connectivity discovery, multi service discovery is the solutions proposed for the corresponding use case. multi-service discovery is more related to ALTO server discovery, I think we may leverage existing mechanism proposed in RFC8686. Multi-connectivity discovery is to expand ALTO path vector mechanism to multi domain setting. Special requirements for multi-domain setting is to carry network information across domain which include domain identifier information, we may also consider to carry compute information, which help combine network information and compute information for service edge discovery.
Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion.
[Qin]:I think one good use case we have is MOWIE use case, i.e., adjust the bitrate to improve Cloud gaming QoE experience based on abstract network information to be exposed. For this use case, we can see a good collaboration between OTT provider and network operation, Probably they sign agreement for the mutual benefits reason. Also network operator will provide aggregate and abstract network information and expose very few information to the client, this is what ALTO is designed for.
The proposed work items related to MOWIE, feel free to review and evaluate it'
[Peng]: Thanks. I talked to Gang about MOWIE before.  It involves some new cooperation modes, which are worthy of further discussion and exploration in details.
[Qin-1]:Besides MOWIE which require collaboration between OTT and network provider, we can also envision that the network provider or MSO deploy some content service or TV service,
These service will be owned and managed by themselves, ALTO service can be one of good option for them to offer the service to their customers.
o Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response. Such policy attributes may indicate information dependency (e.g., ALTO path-cost/QoS properties with dependency on real-time network  indications), optimization criteria (e.g., lowest latency/throughput network performance objective), and constraints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed, diversity and redundancy of paths).
o Protocol extensions for facilitating operational automation tasks and improving transport efficiency. In particular, extensions to provide "pub/sub" mechanisms to allow the client to request and receive a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information. Efforts developed in other working groups such as MQTT Publish / Subscribe Architecture, WebSub, Subscription to YANG Notifications will be considered, and issues such as scalability (e.g., using unicast or broadcast/multicast, and periodicity of object updates) should be considered.
”
Thanks!
Regards,
Peng

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105
email:  [email-masked]<mailto:[email-masked]>

发件人: Qin Wu<mailto:[email-masked]>
时间: 2021/02/22(星期一)21:45
收件人: IETF ALTO<mailto:[email-masked]>;
抄送人: alto-chairs<mailto:[email-masked]>;alto-ads<mailto:[email-masked]>;
主题: [alto] ALTO Draft ReCharter WG review
Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been posted to this list,

---

From: "Wei Wang" <[email-masked]>
Date: Thu, 4 Mar 2021 13:57:21 +0800

Hi all,

&nbsp; &nbsp; I think SD-WAN can be covered by ALTO rechartered work item. SD-WAN can connects the user to any application wherever it resides from the data center to the cloud, and assesses the best path meeting the ideal performance needs for a specific application. SD-WAN can also be used for cross domain scenario.&nbsp;
&nbsp; &nbsp; For example, in some cloud-based WAN communications, stitching multiple overlay tunnels in each domain are used for traffic policy enforcement matters such as optimizing traffic distribution or to select the best SD-WAN Edge for best user experience. A SD-WAN Edge can be partitioned into multiple instance, for some instance which can redirect traffic to the payment GW to offer better quality of service. ALTO protocol can be the best option for SD-WAN Edge selection.

Best Regards,
Wei
China Telecom

====================
 
&nbsp;
 
发件人: Qiao Xiang [mailto:[email-masked]] 
 发送时间: 2021年3月3日  0:18
 收件人: 刘鹏 <[email-masked]&gt;
 抄送: Y. Richard Yang <[email-masked]&gt;; IETF ALTO <[email-masked]&gt;; Qin Wu <[email-masked]&gt;
 主题: Re: [alto] ALTO Draft ReCharter WG review
 
&nbsp;
   
Hi Peng, Qin and Richard,
  
&nbsp;

Very good discussion! Richard and I have been working with folks from CMS and ESNet (a large global multi-domain science network) to design network information exposure abstractions and mechanisms in multi-domain networks, with  privacy requirements considered. The basic idea stems from the ALTO path-vector extension but goes beyond to take privacy into consideration. The following are some pointers.

&nbsp;

[1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery", IEEE JSAC, 2019. (https://ieeexplore.ieee.org/abstract/document/8756056)
 [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", (https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/)
   
&nbsp;

For the pointers above, the privacy requirement considered in this work is that the network information of multiple domains should be exposed to applications as a complete, unified aggregation, appearing as much as possible  as from a single (virtual) network. We design a network information obfuscation mechanism so that the application is not able to associate any network resource bottleneck information to any domain, reducing the risk of exposing network vulnerability.

&nbsp;

In addition, we also studied how to control the routing across multiple domains to achieve more flexible end-to-end interdomain routing. Essentially, we propose a mechanism that allows networks to expose their available  interdomain routes, just as BGP looking glasses, so that applications can control them. In this setting, we consider the privacy setting where each network's BGP export policies are private, and design interesting algorithms for applications to select the  best policy-compliant routes without knowing the export policies. The following is the pointer for this study:

&nbsp;

[3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 (https://ieeexplore.ieee.org/abstract/document/9155486) 

&nbsp;

Above are our current efforts on extending ALTO to multi-domain settings. It would be great if we can know more about the industry efforts on network information exposure in multi-domain settings, and the privacy requirements  of operators. This would be extremely helpful to push this extension forward! :-)

&nbsp;

&nbsp;

&nbsp;

Best

Qiao

&nbsp;
   
On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 <[email-masked]&gt; wrote:

Hi Richard,

&nbsp;

Thank you. please see my reply inline below.

&nbsp;

&nbsp;

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email: &nbsp;[email-masked]

&nbsp;

发件人: Y. Richard Yang

时间: 2021/03/02(星期二)07:36

收件人: 刘鹏;

抄送人: IETF ALTO;Qin Wu;

主题: Re: [alto] ALTO Draft ReCharter WG review

Dear Peng,
  
&nbsp;

 
&nbsp;
   
On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 <[email-masked]&gt; wrote:

Hi WG,
 
&nbsp;

   
&nbsp;

It is good info.

&nbsp;

At present, operators also research in it, which may involve guaranteeing end-to-end network service in the future, such as delay, bandwidth,  etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane.

&nbsp;

&nbsp;Do you want to share some pointers?

&nbsp;

[Peng] As Qin said, it is hard to collect information across network borders.

Just taking deterministic network as an example, it is hard to applying synchronization,  unified forwarding strategy in multi domain, so there are some works need to be done with management plane. Due to the large scale and multi domains or operators, the management system may be distributed.
 
A potential way is to consider negotiating the forwarding time of each domain in advance  and carrying time stamp in the message to control the forwarding path of each domain. While it needs some agreements like contracts to prevent one party from tampering with and denying the management content.
 
Beside this, there may be others use case. I'm not sure if Alto servers are willing to do  those work, but it may be helpful to collect or configure some key information.  
  
&nbsp;

&nbsp;

It looks that you want to consider both modes: multidomains but single operator (i.e., intra-cooperation) and multidomains and multiple operators. Regardless, I agree that it is important for the work to clarify on the  privacy requirements.

&nbsp;

[Peng] Yes, agree.

&nbsp;

Richard

&nbsp;

&nbsp;

&nbsp;

Regards,
 
Peng

&nbsp;

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email: &nbsp;[email-masked]

&nbsp;

发件人: Qin Wu

时间: 2021/02/22(星期一)21:45

收件人: IETF ALTO;

   
 Hi, :

 

&nbsp;

 
&nbsp;

&nbsp;

 
&nbsp;

&nbsp;
 
o Protocol extensions to support a richer and extensible set of policy attributes in ALTO  information update request and response. Such policy attributes may indicate information dependency (e.g., ALTO path-cost/QoS properties with dependency on real-time network&nbsp; indications), optimization criteria (e.g., lowest latency/throughput network performance  objective), and constraints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed, diversity and redundancy of paths). 
 
&nbsp;

&nbsp;

&nbsp;

 
 
&nbsp;
 
o The working group will update RFC 7971 to provide operational considerations for recent  protocol extensions (e.g., cost calendar, unified properties, and path vector) and new extensions that the WG develops. New considerations will include decisions about the set of information resources (e.g., what metrics to use), notification of changes either  in proactive or reactive mode (e.g., pull the backend, or trigger just-in-time measurements), aggregation/processing of the collected information&nbsp; (e.g., compute information and network information )according to the clients’ requests, and integration with  new transport mechanisms (e.g., HTTP/2 and HTTP/3).
 
&nbsp;

 
&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

 

  
&nbsp;

-- 
    
-- 

&nbsp;=====================================

| Y. Richard Yang <[email-masked]&gt; &nbsp; |

| Professor of Computer Science &nbsp; &nbsp; &nbsp; |

|  http://www.cs.yale.edu/~yry/ &nbsp; &nbsp; &nbsp; &nbsp;|

&nbsp;=====================================

 

  
&nbsp;

-- 
       
Qiao Xiang
 Professor,

School of Informatics,

Xiamen University

---

From: Qin Wu <[email-masked]>
Date: Thu, 4 Mar 2021 13:42:38 +0000

Hi, Wei:
Thanks for sharing your SD-WAN use case, very good use case, I think. This case reminds me the LOOP (Local Optimizations on Path Segments) effort in the IETF, which is very similar to CDNI use case, if my understanding is correct,
We can query from SD-WAN Edge peer for its capability and footprint.
To support redirect traffic to the right network node (e.g., Payment gateway) and when SDWAN edge is partitioned into multiple instances, SDWAN instance ID need to be returned.

-Qin
发件人: Wei Wang [mailto:[email-masked]]
发送时间: 2021年3月4日 13:57
收件人: xiangq27 <[email-masked]>
抄送: liupengyjy <[email-masked]>; alto <[email-masked]>; Qin Wu <[email-masked]>
主题: Re: [alto] ALTO Draft ReCharter WG review

Hi all,

    I think SD-WAN can be covered by ALTO rechartered work item. SD-WAN can connects the user to any application wherever it resides from the data center to the cloud, and assesses the best path meeting the ideal performance needs for a specific application. SD-WAN can also be used for cross domain scenario.
    For example, in some cloud-based WAN communications, stitching multiple overlay tunnels in each domain are used for traffic policy enforcement matters such as optimizing traffic distribution or to select the best SD-WAN Edge for best user experience. A SD-WAN Edge can be partitioned into multiple instance, for some instance which can redirect traffic to the payment GW to offer better quality of service. ALTO protocol can be the best option for SD-WAN Edge selection.

Best Regards,
Wei
China Telecom

====================

发件人: Qiao Xiang [mailto:[email-masked]]
发送时间: 2021年3月3日 0:18
收件人: 刘鹏 <[email-masked]<mailto:[email-masked]>>
抄送: Y. Richard Yang <[email-masked]<mailto:[email-masked]>>; IETF ALTO <[email-masked]<mailto:[email-masked]>>; Qin Wu <[email-masked]<mailto:[email-masked]>>
主题: Re: [alto] ALTO Draft ReCharter WG review

Best
Qiao

On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard,

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105

发件人: Y. Richard Yang<mailto:[email-masked]>
时间: 2021/03/02(星期二)07:36
收件人: 刘鹏<mailto:[email-masked]>;
抄送人: IETF ALTO<mailto:[email-masked]>;Qin Wu<mailto:[email-masked]>;
主题: Re: [alto] ALTO Draft ReCharter WG review
Dear Peng,

On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

It is good info.

[Peng] Yes, agree.

Richard

Regards,
Peng

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105

-Qin Wu (on behalf of chairs)
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

--
--
 =====================================
| Y. Richard Yang <[email-masked]<mailto:[email-masked]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/<http://www.cs.yale.edu/%7Eyry/>        |
 =====================================
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

--
Qiao Xiang
Professor,
School of Informatics,
Xiamen University

---

From: Qin Wu <[email-masked]>
Date: Fri, 5 Mar 2021 03:58:42 +0000

Hi,
发件人: Qiao Xiang [mailto:[email-masked]]
发送时间: 2021年3月5日 0:03
收件人: Qin Wu <[email-masked]>
抄送: 刘鹏 <[email-masked]>; Y. Richard Yang <[email-masked]>; IETF ALTO <[email-masked]>
主题: Re: [alto] ALTO Draft ReCharter WG review

Sorry, I missed one comment:

Qin: I believe your case require server to server communication for end-to-end interdomain routing.

My comment: I think we used BGP to provide the e2e interdomain routing information.

[Qin Wu]: Understand,  we don’t need to change route exchange protocol across domain, BGP is the wonderful protocol for this job.

Best
Qiao

On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

Thank you so much for the feedback. Please see my responses inline.

On Thu, Mar 4, 2021 at 9:22 PM Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Qiao for sharing your project on Unicorn and thought on multi-domain setting.
My impression in your implementation is each domain name and first ingress node in such domain will be carried in the ALTO response message.
First, for domain name, I do not believe we need that in the ALTO response message. Our setting here is each domain has an ALTO server, and the ALTO clients at the aggregator have separate connections to different ALTO servers. In this way, by maintaining a (domain, ALTO  server) mapping, the aggregator can differentiate responses from different domains. Second, for ingress node, the client needs to specify the ingress and the (srcIP, dstIP) pair in the query first so that the ALTO server knows what information to return. And I should also clarify that although we use ODL-ALTO for our system, but the path vector extension is not implemented exactly following the specification since it was not fully stabilized then.

[Qin Wu]: I think we can use BGP for inter domain route exchange, we can use ALTO path vector for multi-domain peer selection or path selection. Right now, I think path vector hasn’t been designed for multi-domain setting, if my understanding is correct.
But PCEP has already supported multi-domain path computation.

@Jensen is the core developer and can comment further on this, as well as the ODL implementation.

One thing I want to highlight is
Unicorn has already been deployed in several cities of USA in 2018 and implemented in the ODL open source.
I should clarify that this deployment is pre-production, and the demonstration scenario is at SC18 and SC19, where we are at the conference cities (Dallas and Denver), and orchestrate traffic from there back to a Caltech LHC site (we manually separate this site into two domains to create a 3-domain scenario for demonstration purpose.)

[Qin Wu]: I see. Thank Qiao for clarification.
Quote from https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/
“
   The authors build an ALTO server on top of the OpenDaylight Software
   Defined Network controller.  The ALTO server collects the network
   state information from the OpenDaylight controller, e.g., topology,
   policy and traffic statistics, processes the collected information
   into resource abstraction, and sends the abstraction back to the ALTO
   client at the resource orchestrator.

The Unicorn framework has been deployed and
   demonstrated in small federation networks connecting Dallas, Texas,
   Los Angles, California, and Denver, Colorado at different
   conventions.  For example, in 2018, the federation in the
   demonstration is composed of three member networks.  Network 1 is in
   Dallas, Texas, and Network 2 and network 3 are in Los Angeles,
   California.  Network 1 is connected to network 2 through a layer-2
   WAN circuit with a 100 Gbps bandwidth, provisioned by several
   providers such as SCinet, CenturyLink and CENIC.  Network 1 is a
   temporal science network in the CMS experiment, while network 2 and 3
   are long-running CMS Tier-2 sites.
”
I believe your case require server to server communication for end-to-end interdomain routing.

Secondly, as for network information exposure in multi-domain setting, I think
1. 3GPP Network Exposure Function is a good example for network information exposure, but it is part of 5G core which enables data exchange between UE and application server and does not extend to other domain.
2. ZSM multi-domain network and service management can be another concrete example for multiple domain network information exposure which can be used to have a quick
response to network anomaly or reroute the traffic to the less congested path [https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf].
3. PCE has similar design for multi-domain setting, which allows PCE to PCE communication.

Thank you again for the pointers. I'll take a look at ZSM and PCE soon.

Best
Qiao

-Qin
发件人: Qiao Xiang [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2021年3月3日 0:18
收件人: 刘鹏 <[email-masked]<mailto:[email-masked]>>
抄送: Y. Richard Yang <[email-masked]<mailto:[email-masked]>>; IETF ALTO <[email-masked]<mailto:[email-masked]>>; Qin Wu <[email-masked]<mailto:[email-masked]>>
主题: Re: [alto] ALTO Draft ReCharter WG review

Best
Qiao

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105

It is good info.

[Peng] Yes, agree.

Richard

Regards,
Peng

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105

--
Qiao Xiang
Professor,
School of Informatics,
Xiamen University

--
Qiao Xiang
Associate Research Scientist,
Department of Computer Science,
Yale University

--
Qiao Xiang
Associate Research Scientist,
Department of Computer Science,
Yale University

---

From: 刘鹏<[email-masked]>
Date: 05 Mar 2021 15:28:33 +0800

Hi Qin,

Please see inline.

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

发件人: Qin Wu

时间: 2021/03/03(星期三)17:11

收件人: 刘鹏;

抄送人: IETF ALTO;

主题: RE: RE: [alto] ALTO Draft ReCharter WG review 

Hi, Peng: 

 

Hi Qin, 

   

Peng Liu | 刘鹏  

China Mobile | 移动研究院  

mobile phone：13810146105  

 

Hi WG,   

 [Peng-1]  It is a challenge but valuable I think, we also initiated a work item“Requirements and framework of  Deterministic QoS in large-scale telecommunications networking for IMT-2020 networks and beyond"   in ITU-T, which includes discussing the multi domain requirments in deterministic network.  

[Peng-1] : Good idea and I think it may help the network and benifit some new services in the furture.

” 

Thanks! 

Regards, 

Peng  

 

 Peng Liu | 刘鹏  

 China Mobile | 移动研究院  

 mobile phone：13810146105  

   

发件人: Qin Wu  

时间: 2021/02/22(星期一)21:45  

收件人: IETF ALTO;  

 Hi, :

---

From: Qin Wu <[email-masked]>
Date: Tue, 9 Mar 2021 01:55:00 +0000

Hi, Kai:
发件人: alto [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2021年3月8日 17:44
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]; [email-masked]; 'IETF ALTO' <[email-masked]>
主题: Re: [alto] ALTO Draft ReCharter WG review

Hi Gang and Qin,

I am also interested in the details of the use case. Like I mentioned, ALTO already has an extension (RFC 8895) that allows one-to-one pub/sub, it would be useful if the use case can show that the current design, despite that it is built on top of SSE, is not enough to support similar common use cases. My guess is that there are some synchronization requirements that the subscribers are intended to make decisions based on the same ALTO information? So aside from Qin's question on the traffic pattern, it would be wonderful if the use case can illustrate the distribution of ALTO information.

[Qin]: Good point, When NETCONF WG is talking about their next step or new work last night, NETCONF over HTTP 2/ HTTP 3 had been brought up and got a lot of attention. Therefore I think it will be valuable for us to investigate how ALTO can migrate transport from HTTP 1.0 to HTTP 2/HTTP3 and leverage underlying capability as well.

One question come up from NETCONF discussion, is whether NETCONF should allocate new port for new transport. I am not sure this issue applies to ALTO protocol as well.

I am also a bit confused about what one-time subscription means here. Is it one-time for a single subscriber or multiple subscribers? If for a single subscriber, I do not see why the subscriber would make the same subscription many times. It would wonderful if we can clarify this in the use case.

[Qin]:I believe it is terminology issue, I think we can have on demand subscription, and periodical subscription. One time subscription is similar to on demand subscription. Refer to gNMI for the similar term (https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#35-subscribing-to-telemetry-updates):

" A client may create a subscription which has a dedicated stream to return one-off data (ONCE); a subscription that utilizes a stream to periodically request a set of data (POLL); or a long-lived subscription that streams data according to the triggers specified within the individual subscription's mode (STREAM).

"

Best,

Kai

-----Original Messages-----
From:"Qin Wu" <[email-masked]<mailto:[email-masked]>>
Sent Time:2021-03-08 10:51:31 (Monday)
To: "Li Gang" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "'IETF ALTO'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [alto] ALTO Draft ReCharter WG review
Hi, Gang:
Thanks for sharing your use case, let me rephrase what you envision for your use case,
You want to express QoS requirement in the subscription request, the network exposes the network information via notification in response to subscription request,
application operators can tune adaptive rate to improve user QoE based on the network information change.

Can you clarify a little bit about specific application traffic patterns?

Secondly, I agree fine granularity pub sub can consider one time subscription and configure wait time as subscription policy to alleviate the signaling load on the network.

-Qin
发件人: Li Gang [mailto:[email-masked]]
发送时间: 2021年3月7日 16:30
收件人: [email-masked]<mailto:[email-masked]>; Qin Wu <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'IETF ALTO' <[email-masked]<mailto:[email-masked]>>
主题: RE: [alto] ALTO Draft ReCharter WG review

Hi, Kai and Qin,

Thanks for triggering the discussion on  the 2nd item of the recharter text.
I agree that it would be better to define a generic pub/sub framework irrespective of specific transport protocol.
We can start with a simple pub/sub mechanism, which is driven by concrete use cases and then consider to extend as needed.

Some of my thoughts are inline.

Li Gang

From: alto [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, March 5, 2021 11:03 AM
To: Qin Wu
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; IETF ALTO
Subject: Re: [alto] ALTO Draft ReCharter WG review

Hi Qin,

Thanks for the comments. A quick summary of my response is

1. "Pub/sub" means different things in different contexts and I think we must clarify what it means in the context of distributing ALTO information.

2. There are two ways of realizing complex "pub/sub" of ALTO information but I think they are fundamentally different deployment settings for one generic framework (whose details are, unfortunately, not thought through yet).

Please see the details inline.

Best,

Kai

-----Original Messages-----
From:"Qin Wu" <[email-masked]<mailto:[email-masked]>>
Sent Time:2021-03-04 22:21:06 (Thursday)
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "IETF ALTO" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [alto] ALTO Draft ReCharter WG review
Kai:
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2021年3月3日 21:40
收件人: Qin Wu <[email-masked]<mailto:[email-masked]>>
抄送: IETF ALTO <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [alto] ALTO Draft ReCharter WG review

Dear all,

Below are some comments on the 2nd item in the recharter text.

As far as I know, the ALTO incremental update extension (RFC 8895) already provides a mechanism to enable the "pub-sub" of ALTO information, using Server-Sent Events (SSE). I see there are multiple directions indicated by the new charter item:
[Qin]: Thanks for clarifying the difference between SSE and pub sub proposed in the new proposed charter item.

1. Decouple the "pub-sub" protocol with the underlying mechanism.

Besides SSE, other mechanisms can also be used to realize the "pub-sub" of ALTO information, such as HTTP/2, HTTP/3 or the methods mentioned in the charter text. Thus, a direct extension is to define the abstract format of control messages and data messages (i.e., WHAT information should be provided but not HOW), and allow different underlying protocols to use protocol-specific encodings.

For example, SSE encodes the metadata (e.g., content-type and stream id) and the content of an event using "event:" and "data:" prefixes at the beginning of each line, and uses empty lines to indicate the end of a message, while HTTP/2 (RFC 7540) may encode the metadata and the content of an event using PUSH_PROMISE/HEADERS and DATA frame .

[Qin]: Good analysis, I think we need to decide whether we should define generic pub sub mechanism or transport specific pub sub mechanism. Do you have any suggestion on this?

[KAI]: I think the generic pub-sub mechanism (or maybe the term framework is more appropriate) is more important at this point, which should also cover the direction of providing more fine-grained control. One thing that just strikes me after taking a quick look at rabbitMQ is that "pub/sub" means different things in different contexts. It is important we understand what are the requirements of generic pub/sub in the ALTO framework.

[KAI]: When we discuss "pub/sub" with SSE and HTTP/2, which is a one-to-one client-server communication, the focus of the "pub/sub" here is simple: what are the messages and how the client can control the subscribed information. However, with message queues (e.g., rabbitMQ), the communication pattern may be more complex: a message can be sent to multiple queues without knowing exactly who is subscribing. I see two ways to realize the more complex "pub/sub" requirement for ALTO information.

rabbitMQ: https://www.rabbitmq.com/tutorials/tutorial-three-python.html

[KAI]: CASE A: First, the client application may use deploy its own "pub/sub" system, and the ALTO client simply serves as a producer by forwarding the ALTO messages to the "pub/sub" system. In this way, the problem is reduced to the one-to-one "pub/sub" problem.

[KAI]: CASE B: Second, ALTO servers may natively support the "pub/sub" of ALTO information. In this case, an ALTO server may need to handle events such as join/leave of clients that subscribe to the same ALTO information. For example, for a client that just subscribes to a network map, the server should send the whole map instead of incremental updates.

[KAI]: Both approaches have pros and cons. The first is simple on the server side but may be less efficient (because of triangle routing) and complex on the client side (client must handle data consistency to support dynamic subscribers). I think the generic framework should contain two aspects:

[KAI] 1. Control of ALTO information: a server-client protocol which is similar to RFC 8895 but maybe with some extended capabilities.

[KAI] 2. Distribution of ALTO information: a MQ-like protocol that controls how the ALTO information can be efficiently and consistently delivered to subscribers.

[KAI] I think the connection between these two aspects is a logical entity called ALTO Exchange (following the term used by rabbitMQ). This entity can be operated by an application provider (as in CASE A) or by a network operator (as in CASE B). However, the detailed responsibilities of this entity may still need some investigation.

I think this requirement may help integrating ALTO in network management platforms (such as OpenDaylight, Kubernetes, and ETSI ZSM*) which design their own pub-sub systems for reasons such as consistency or ease of development. It would be great if there is an interest in this direction from companies/organizations.

[Qin]: I can see The 3GPP has defined a Service-Based Architecture (SBA), whereby the control plane functionality and common data repositories of a 5G network are delivered by way of a set of interconnected Network Functions (NFs),pub sub mechanism has been well adopted in 3GPP interface.

Also in the public cloud, popular pub/sub implementations has been widely deployed,e.g., rabbitMQ (AMQP), mosquitto (MQTT), ejabberd (XMPP), and ZeroMQ. We also see many pub sub mechanism or extension has been developed in IETF, e.g., YANG Push, draft-ietf-dots-telemetry, draft-ietf-ace-mqtt-tls-profile.

* The integration fabric of ETSI ZSM provides pub-sub support but ZSM also allows services to use their own pub-sub mechanisms.

2. Enable more fine-grained control of pub-sub.

In RFC 8895, there are two types of commands which only defines WHAT information to subscribe:

- add: Make one or more new requests to receive the incremental updates.

- remove: Terminate the subscription of one or more previously-made requests.

In the meantime, the updates will be continuously sent to the client whenever a server sees fit.

The charter text proposes to enable ALTO clients to request and receive "a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information". It seems to me that the new extension wants to allow clients to specify not only WHAT information to be subscribed but also WHEN/HOW the information should be delivered (e.g., Notify me the latest value every 5 second.).

[Qin]:Good point, I think fine grained control of pub-sub allows not only periodical subscription, but also on demand subscription, which is the missing piece in the existing SSE incremental update.

[Gang]: I think WHAT/WHEN/HOW should all be considered for pub/sub. Specifically, after one time subscription, notification may be one time, multiple times based on either event triggering or periodic reporting. Besides that, in order to reduce signaling overhead, maybe minimum wait time can be defined between consecutive pub messages.

Personally I find both directions to be interesting and useful. It would be great if they can be supported by real use cases.

[Gang]: I also agree that the necessary extension should be well supported by concrete use cases. I’d like share some thoughts on use cases in my mind: some application operators would like to subscribe the QoS requirements（maybe one or a list）for their specific application traffic patterns to the network operators, the network can provide notification whether/how the network would fulfill their requirements, so that application operators can perform adaptive rate control to improve user QoE.

Just my two cents.

Best,

Kai

-----Original Messages-----
From:"Qin Wu" <[email-masked]<mailto:[email-masked]>>
Sent Time:2021-02-22 21:50:44 (Monday)
To: "IETF ALTO" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [alto] ALTO Draft ReCharter WG review
Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been posted to this list,

---

From: 刘鹏<[email-masked]>
Date: 12 Mar 2021 11:24:40 +0800

Hi Richard,

Thanks for sharing your idea！ I think it's necessary to considering the security and privacy issues.

The framework of differential privacy can be a potential choice to protect individual or detail privacy of network without encryption which might influent the efficiency of information exchange, while it need to consider the data availability.

Regards,

Peng

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

发件人: Y. Richard Yang

时间: 2021/03/10(星期三)10:32

收件人: Qiao Xiang;

抄送人: 刘鹏;IETF ALTO;Qin Wu;

Hi Peng, all,

Thanks a lot for the excellent discussions. It is clear that multi-domain is a major issue to resolve, as multidomain is the general deployment setting where resource consumers and providers are in the general case deployed in multiple networks. 

To proceed with the recharter discussion, I suggest that we conduct basic security and privacy analysis to see if we are ready for recharter; that is, we have a basic understanding of related issues so that it is ready for design, not still in the early research stage. For security, we can start with focusing on the basic requirements including authenticity, integrity, and confidentiality. For privacy, we can start with a framework such as differential privacy analysis.

To me, a basic model of a multi-domain alto information service is the following:

- a set of (potential) resource providers s1, s2, ..., 

- a set of (potential) resource consumers c1, c2, c3, ...

The foundation of the alto service is to provide the costs of the paths {si -> cj}; I always think of alto as an extension of DNS, which is mainly for endpoints in a graph and alto is paths. In a single domain setting, all entities, {si}, {cj}, {si->cj} are within a single domain and hence the main security/privacy issue is the security/privacy issue of between the single alto server representing the single domain and the alto client. For security, the domain can leverage any one of the security systems (e.g., using public keys to bootstrap the system); for privacy, the application (client) and the network (server) are two parties, and they can agree on an acceptable privacy model.

Now, in a multi-domain setting, each entity may have a different domain (or a sequence of domains for a path). Now, both ALTO client and ALTO server will have additional security and privacy issues. 

- For the ALTO client, the information can now come from multiple networks; assume the information info(n1, n2, ...)  is computed from those from multiple networks n1, n2, ... Then the basic security issue is how the client can verify the authenticity of the information. 

- For an ALTO server, the server may not have a direct trust relationship with the client; for example, when the ALTO server is only in the chain of a path, not the client-facing server. Hence, the server may not have a relationship to specify the privacy requirement.

The preceding are challenging issues. It is clear that security and privacy issues depend on the specific design. Hence, we target a "lower-bound" analysis, by considering a base design that can address main security and privacy issues. The WG can decide on the specific design which is better than the basic design.

During the design meetings, we have considered the following "base-line" design for a "lower-bound":

-  We provide a basic path discovery service to discover the path segments. We can use BGP security to bootstrap the security of the discovered paths. 

- We build verifiable aggregation (i.e., the preceding info function) so that the information can then be individually verified. 

- The remaining issue is how each server can control the privacy of its information, as it may not have a direct relationship with the client. For this, we suggest to start with basic public information, and gradually build trust.

The preceding is high level. A first task, if multidomain is charted, is to write down the details, beyond the existing drafts. I do agree that this analysis and requirements is a good starting, based on the specified use cases.

We can go over the details in our design meeting in the next few following weeks.

Richard

On Tue, Mar 2, 2021 at 11:18 AM Qiao Xiang <[email-masked]> wrote:

Best

Qiao

On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 <[email-masked]> wrote:

Hi Richard,

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

发件人: Y. Richard Yang

时间: 2021/03/02(星期二)07:36

收件人: 刘鹏;

抄送人: IETF ALTO;Qin Wu;

Dear Peng,

               

Hi WG,

It is good info.

  

[Peng] Yes, agree.

Richard

  

Regards,  

Peng

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

发件人: Qin Wu

时间: 2021/02/22(星期一)21:45

收件人: IETF ALTO;

Hi, : 

-Qin Wu (on behalf of chairs)     _______________________________________________
 alto mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/alto