Re: [alto] ALTO Draft ReCharter WG review

[刘鹏 <[e-mail]>]

Hi Qin,

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








Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：[phone]

email:  [e-mail]


 

 

 

Hi WG,

 

Here are some considerations of recharter: 

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：[phone]  

 

email:  [e-mail]    

 

   

 

 

发件人: 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)