[alto] Meeting minutes for Nov 10, 2020

[[e-mail]]

Dear all,




Please find below the meeting minutes for the weekly meeting on Nov 10, 2020.


Agenda:

- Multi-domain
- First hop information
- General extensions
- New transport

== multi-domain ==

At the beginning of the first topic, Sebastian emphasized that the only control of an ALTO client is to select which peers to connect to, e.g., without the ability to control routing mechanisms such as PCE, MPLS.

Richard presented a design providing a multi-domain abstraction to clients. It returns a path vector of costs, where each cost is obtained from the ALTO server of a domain. This avoids the aggregation of cost values from different ALTO servers, as they may use different methods to compute the path cost, and leaves the responsibility of aggregating the costs to the application.

A query first involves a segment discovery service, where an ALTO server provides the IP address of the exit point for each <src, dst> pair in its network. Then costs are obtained from all the segments involved and are organized as vectors.

The query may operate in two modes: iteractive mode and recursive mode.

Sebastian suggested that the url of the alto server that is in control can be added to the segment discovery. He also mentioned that black holes can be skipped: if a server knows that the next domain does not have an ALTO server, it can send the request to the next network that has one.

Sebastian also raised the problem of what are the benefits of the clients (by exposing BGP-like information). He mentioned that in Deutsche Telekom networks, one AS may already aggregate many networks, different from Comcast which, as Richard mentioned, consists of many ASes.

Sabine proposed that one potential way to identify the benefits is to define properties of the ANEs that may draw the interest of the clients.

== first-hop ==

Gang gave a wonderful presentation on providing first-hop (cellular) information to ALTO clients. His mentioned that many applications are moving to the cloud with the deployment of 5G, cellular information is important for such applications, and trials have proven that such information is beneficial.

He also raised several issues and solutions.

1. Whether it is feasible to obtain the cellular information?
 
Gang mentioned that NEF  in 5G can be used to collect information, and 3GPP-17 also provides a IB+OB mechanism to expose such information. The information of the radio network is first collected by the UPF using IB signals and then be forwarded to the local NEF.

2. How does ALTO obtain info from 5G NEF?

This can be achieved using a RESTful API, e.g., the one proposed in the MoWIE draft.

3. What info is from server to the client?

Two types of information are proposed.

Measurement info: throughput, latency
predicted info: avaiable bandwidth in future time intervals

4. What info is from 5G to the server?

Gang suggested the metrics be defined from best practices.

He also discussed remaining issues such as providing the information in a multidomain scenario.

Richard suggested a shorter version of the document should be provided as a potential charter item.

Sabine suggested CQI is also an imporant metric that can be extracted and exposed, which also is related to a mobile app's performance. She also brought up the issues of dynamics, i.e., radio networks can generate information at very high paces and what is the dynamics a ALTO server/client can sustain.

Chunshan suggested that we first decide radio parameters should be exposed. Only when we have defined the metrics, then we can determine how fast the parameters can be changed.





== other topics ==




Due to the time constraints, the general extensions and new transport are not discussed in the meeting. And the topics will be sent to the mailing list for offline discussion.




Best,

Kai