[alto] Meeting minutes for Nov 10, 2020

kaigao@scu.edu.cn Wed, 11 November 2020 01:37 UTC

Return-Path: <kaigao@scu.edu.cn>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67D3A12AA for <alto@ietfa.amsl.com>; Tue, 10 Nov 2020 17:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9UQFvlny5DE for <alto@ietfa.amsl.com>; Tue, 10 Nov 2020 17:37:50 -0800 (PST)
Received: from zg8tmty1ljiyny4xntqumjca.icoremail.net (zg8tmty1ljiyny4xntqumjca.icoremail.net [165.227.154.27]) by ietfa.amsl.com (Postfix) with SMTP id 138213A12A6 for <alto@ietf.org>; Tue, 10 Nov 2020 17:37:49 -0800 (PST)
Received: by ajax-webmail-app1 (Coremail) ; Wed, 11 Nov 2020 09:37:44 +0800 (GMT+08:00)
X-Originating-IP: [171.214.214.195]
Date: Wed, 11 Nov 2020 09:37:44 +0800 (GMT+08:00)
X-CM-HeaderCharset: UTF-8
From: kaigao@scu.edu.cn
To: alto@ietf.org, "alto-weekly-meeting@googlegroups.com" <alto-weekly-meeting@googlegroups.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.13 build 20200820(b2b8cba1) Copyright (c) 2002-2020 www.mailtech.cn mail
Content-Type: multipart/alternative; boundary="----=_Part_307223_1106240250.1605058664342"
MIME-Version: 1.0
Message-ID: <5d7d4d3d.15184.175b4f39797.Coremail.kaigao@scu.edu.cn>
X-Coremail-Locale: en_US
X-CM-TRANSID: 4wAACgAXHsZoQKtf0ysPAQ--.30329W
X-CM-SenderInfo: 5ndlwt3r6vu3oohg3hdfq/1tbiAQIPB138kkZcxwAbs+
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VW3Jw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/ussAmanuk5l4bu48lJtxqj4nrx8>
Subject: [alto] Meeting minutes for Nov 10, 2020
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 01:37:52 -0000



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