Re: [alto] Welcome Qin Wu(Internet mail)

[熊春山]

Hello all,

Welcome Qu Win  as new chair of the ALTO.

BRs,
Chunshan Xiong
Tencent

From: alto  On Behalf Of Y. Richard Yang
Sent: Wednesday, November 11, 2020 12:47 PM
To: Martin Duke ; Qin (Bill) Wu 
Cc: IETF ALTO 
Subject: Re: [alto] Welcome Qin Wu(Internet mail)

Thanks a lot for choosing a wonderful chair for ALTO, Martin!

Qin: It is wonderful to have you and work with your guidance!

Richard

On Mon, Nov 9, 2020 at 10:48 PM Martin Duke 
mailto:martin.h.d...@gmail.com>> wrote:
Hello ALTO,

I'm pleased to welcome Qin Wu as the newest working group chair, effective 
immediately. Qin is and active participant in ALTO and an experienced chair.

We will have three chairs at IETF 109. Shortly afterwards, one of the current 
chairs will step down. As we complete the current milestones, I will appoint a 
second chair to free both Jan and Vijay to move on to other things.

See you next week,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--
--
 =
| Y. Richard Yang mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Welcome Qin Wu

[Y. Richard Yang]

Thanks a lot for choosing a wonderful chair for ALTO, Martin!

Qin: It is wonderful to have you and work with your guidance!

Richard

On Mon, Nov 9, 2020 at 10:48 PM Martin Duke  wrote:

> Hello ALTO,
>
> I'm pleased to welcome Qin Wu as the newest working group chair, effective
> immediately. Qin is and active participant in ALTO and an experienced chair.
>
> We will have three chairs at IETF 109. Shortly afterwards, one of the
> current chairs will step down. As we complete the current milestones, I
> will appoint a second chair to free both Jan and Vijay to move on to other
> things.
>
> See you next week,
> Martin
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Meeting minutes for Nov 10, 2020

[kaigao]

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  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

[alto] ALTO recharter update: ALTO services in multi-domain settings

[Y. Richard Yang]

Dear ALTOers,

One item which we discussed this morning during our weekly meeting is ALTO
extension to multi-domain settings. Please see attached for the deck of
slides that we used.

At a high level, it tried to extend ALTO into a multi-domain setting for
one of the most basic ALTO services --- endpoint cost services. One item
which was raised, but not included in the slides is to make clear the use
cases, i.e., how the multiple-domain information is used. We sure will
update soon, before and during the WG meeting. Any questions and/or
comments are highly welcome.

Richard


alto-multidomain-2020-11-10.pptx
Description: MS-Powerpoint 2007 presentation
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO recharter: proposed item - General ALTO protocol extensions

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Dear all,

Please find below a WG item proposal for "general ALTO protocol extensions", on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps to determine when to connect
o Extends endpoints to entities on which properties are defined

-- Basic Issues
+++  Issue 1: Some path cost values may depend on "contextual parameters" such 
as access type, SLA, policy or other indicators provided by network. In 
particular:
  - There may be different possible paths between source and 
destination, where some paths may or may not meet Application QoE or policy 
constraints. The Applications would like to see which path is most suitable.
  - Contextual parameters may be available at frequencies that are 
different from ALTO information frequency. For example, Cost on PID-Cell1 may 
differ, depending on some real-time network parameter value.

+++ Issue 2: Some entities may have properties whose values change over time. 
For instance, ANEs may have time-varying properties on cloud or networking 
resources

-- Potential solution(s)
+++  To address issue 1 and related : extend cost attributes towards 
conditional values and parameters allowing a better interpretation of the 
received values
- Extension from single cost value to array of values dependent on context 
parameters:
allowing applications to make context-dependent decisions,
allowing also to combine information generated with different time dynamics, 
(freshness)
See examples on 
https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/

+++  To address issue 2:
- ALTO Property Calendars to extend a single property value to an array of 
time-dependent property values

-- Remaining issues to be addressed
- How to define cost value attributes?
- How to achieve a light and flexible design?
- How to moderate additional Server workload and ALTO traffic increase?

-- Who will work on it, rough planning
+++  Extensions may go in standalone documents and/or extend existing ones, eg 
ALTO performance metrics
+++ Contributors: Sabine and any other interested people
+++ Plans for IETF 110:
  -  Reactivation and update of related existing ALTO drafts
  -  First draft for ALTO Property Calendars
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto