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

From: 刘鹏<[email-masked]>
Date: 02 Mar 2021 13:14:18 +0800

Hi Richard,

Thank you. please see my reply inline below.

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  [email-masked]

发件人: Y. Richard Yang

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

收件人: 刘鹏;

抄送人: IETF ALTO;Qin Wu;

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

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?

[Peng] As Qin said, it is hard to collect information across network borders.            Normal   0            7.8 磅   0   2      false   false   false      EN-US   ZH-CN   X-NONE                                                                                 MicrosoftInternetExplorer4                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

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.   

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.

[Peng] Yes, agree.

Richard

  

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;

主题: [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: Qiao Xiang <[email-masked]>
Date: Wed, 3 Mar 2021 00:17:59 +0800

Hi Peng, Qin and Richard,

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.

[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/)

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.

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:

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

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! :-)

Best
Qiao

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

> email: * [email-masked] <[email-masked]>*
>
>
> 发件人: Y. Richard Yang <[email-masked]>
> 时间: 2021/03/02(星期二)07:36
> 收件人: 刘鹏 <[email-masked]>;
> 抄送人: IETF ALTO <[email-masked]>;Qin Wu <[email-masked]>;
>> 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.
>>
>
> [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.
>
> 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.
>
> [Peng] Yes, agree.
>
> 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]>;
>> 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).
>>
>> 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
>>
>> - 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]
> _______________________________________________
> alto mailing list
> [email-masked]

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Mar 2021 21:31:46 -0500

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:

>>> 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.
>>>
>>
>>> 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
>>> 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: Qiao Xiang <[email-masked]>
Date: Wed, 10 Mar 2021 21:34:27 +0800

Hi Richard,

Thanks for sharing your thoughts and the base line. I'll also think about
the security/privacy issues in multi-domain settings in the next few weeks.

Best
Qiao

On Wed, Mar 10, 2021 at 10:31 AM Y. Richard Yang <[email-masked]> wrote:

> 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
> 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
> 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.
>
> -  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.
> 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
>> For the pointers above, the privacy requirement considered in this work
>> is that the network information of multiple domains should be exposed to

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