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
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
