Re: [alto] Meeting info for Nov 17, 2020

[Y. Richard Yang]

Hi Qin, Chunshan, Gang,

Yes indeed a post of item 4. What I thought missing is the one paragraph.
Did I miss it :-(

Richard

On Mon, Nov 16, 2020 at 10:48 PM Qin Wu  wrote:

> Richard, Kai:
>
> I think the item 4 has been posted by proponents on the list, which is
> available at
>
> https://mailarchive.ietf.org/arch/msg/alto/9CAIL0hEW4cy90iVeOJn_gYO84o/
>
> we miss item 2 and 3.
>
>
>
> -Qin
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Y. Richard Yang
> *发送时间:* 2020年11月17日 11:02
> *收件人:* Kai Gao 
> *抄送:* alto-weekly-meet...@googlegroups.com; IETF ALTO 
> *主题:* Re: [alto] Meeting info for Nov 17, 2020
>
>
>
> Thanks a lot, Kai!
>
>
>
> I saw from the WG mailing list the proposed paragraphs on items 1 and 5.
> It will be nice if the leads of 2-4 can post the initial proposals before
> the meeting soon...
>
>
>
> Richard
>
>
>
> On Mon, Nov 16, 2020 at 8:17 AM  wrote:
>
> Dear all,
>
> We will have the last meeting before the IETF 109 ALTO session at 9:00 am
> US EST (3 pm CET, 10 pm Beijing Time).
>
> The purpose is to go over and finalize the recharter items. Given that
> some topics were not presented in the last meeting, I suggest we follow the
> order below:
>
> 1. General extensions
>
> 2. New transport
>
> 3. Operation automation
>
> 4. First hop
>
> 5. Multi-domain
>
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
>
> Best,
>
> Kai
>
> ___
> 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/|
>
>  =
>
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting info for Nov 17, 2020

[Qin Wu]

Richard, Kai:
I think the item 4 has been posted by proponents on the list, which is 
available at
https://mailarchive.ietf.org/arch/msg/alto/9CAIL0hEW4cy90iVeOJn_gYO84o/
we miss item 2 and 3.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang
发送时间: 2020年11月17日 11:02
收件人: Kai Gao 
抄送: alto-weekly-meet...@googlegroups.com; IETF ALTO 
主题: Re: [alto] Meeting info for Nov 17, 2020

Thanks a lot, Kai!

I saw from the WG mailing list the proposed paragraphs on items 1 and 5. It 
will be nice if the leads of 2-4 can post the initial proposals before the 
meeting soon...

Richard

On Mon, Nov 16, 2020 at 8:17 AM mailto:kai...@scu.edu.cn>> 
wrote:

Dear all,

We will have the last meeting before the IETF 109 ALTO session at 9:00 am US 
EST (3 pm CET, 10 pm Beijing Time).

The purpose is to go over and finalize the recharter items. Given that some 
topics were not presented in the last meeting, I suggest we follow the order 
below:

1. General extensions

2. New transport

3. Operation automation

4. First hop

5. Multi-domain



Bridge: https://yale.zoom.us/my/yryang



Best,

Kai
___
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] ALTO recharter: proposed item - General ALTO protocol extensions

[Qin Wu]

Hi, Sabine:
Thanks for the update on the proposed item.
See my comments inline.
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
发送时间: 2020年11月17日 1:16
收件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
主题: Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

The paragraph below is proposed to define the WG item on “general protocol 
extensions”.
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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
[Qin]:Good, I believe you talk about Path vector, ALTO cost calendar, and 
unified properties which provide a good basis for any new work.
-- 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.
[Qin]: I see this contextual parameter as path constraints,  besides access 
type, SLA, policy, I think end to end latency, packet loss can also see as path 
constraints, which can help select a connection path to meet network 
performance requirements.
Also I think the specific intermediate network elements, transit administrative 
domain traversed by the flow identified by source destination pair can also be 
seen as contextual parameter, e.g.,  we have two end to end paths, we can have 
contextual parameter like:
route the path through transit domain A, route the path not through transit 
domain B.

or  if (service_destination matches 10.132.12.0/24)
   Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1.


+++ 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
[Qin]: ANE having time varying properties on cloud or networking resource, can 
ANE be set as destination end point, I think we should distinguish whether 
properties are owned by destination endpoint or intermediate network element?
For the former case, we may use for service edge selection in the edge 
computing case, the properties could be the load, capability. For intermediate 
network elements, one example property is timestamp or queue length, let me 
know what is your example properties?
-- 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 iss

Re: [alto] Meeting info for Nov 17, 2020

[Y. Richard Yang]

Thanks a lot, Kai!

I saw from the WG mailing list the proposed paragraphs on items 1 and 5. It
will be nice if the leads of 2-4 can post the initial proposals before the
meeting soon...

Richard

On Mon, Nov 16, 2020 at 8:17 AM  wrote:

> Dear all,
>
> We will have the last meeting before the IETF 109 ALTO session at 9:00 am
> US EST (3 pm CET, 10 pm Beijing Time).
>
> The purpose is to go over and finalize the recharter items. Given that
> some topics were not presented in the last meeting, I suggest we follow the
> order below:
>
> 1. General extensions
>
> 2. New transport
>
> 3. Operation automation
>
> 4. First hop
>
> 5. Multi-domain
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
> Best,
>
> Kai
> ___
> 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

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

[Y. Richard Yang]

Hi Sabine,

Thanks a lot for the paragraph describing a potential recharter item.

I have three quick comments, according to my understanding:

- [C1] The extension will focus on "additional" information such as
conditions/context on entities (e.g., extend unified properties) and path
costs (e.g., extend endpoint cost services, cost map services). I can see
such a capability as an instance of a generic capability to allow more
efficient information distribution; that is, instead of asking the server
each every time, the client is given the condition/policy and the
information, and the client can decide, locally, whether to use the
information (and/or what information is applicable). I see two benefits:
(1) reduce the latency for the client to query (and reduce server load
during congestion), and (2) potentially reduce information (e.g., instead
of A, B, A, B from server to client when the condition/context switches
between two states, the server send A and B and the condition to watch
for). Is this the right way to understand the benefits of the item? If so,
it may help to add sentences on the issues that the item addresses (e.g.,
low efficiency of information distribution)?

- [C2] If the preceding understanding is correct, then maybe the item can
be described using a more specific term, instead of the generic term of
general protocol extension. Also, the condition/context still appears to
help a client to decide "where" and "when" to connect but also under which
conditions, with the "when" being understood in both temporal (time) and
logical senses. Hence, I feel that some clarification of the term can help.

- [C3] Moving from the "problem" (why) part to the "feasibility" (how)
part. How about we constrain the design space some more? For example, one
can envision using the power of the full mathematical logic (simple Boolean
logic, temporal logic, ...) to specify the context/conditions. This can be
powerful but also may be complex to finish in a target time frame of say
only 1-2 years.

Talk to you tomorrow and we can go over some more details to wrap up.

Richard

On Mon, Nov 16, 2020 at 12:35 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hello,
>
>
>
> Please find below a revision of the proposed definition paragraph.
>
> This WG item is further detailed in the Google doc available here (page
> 19/25):
>
>
> https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit
>
>
>
> Thanks,
>
> Sabine
>
>
>
> 
>
> General protocol extensions to convey a richer set of attributes allowing
> to determine not only "where" and "when" to connect but also under which
> conditions. Such additional information will be related both to entities
> (e.g. conveying time-averaged server load in data center supported
> applications) and to path costs (e.g. ALTO path cost value depending on
> conditions such as real-time network indications or SLA or policy or
> access-type or indicator type).
>
>
>
> The working group will specify such extension in coordination with both
> other ALTO working group items and IETF working groups that have a focus on
> the related use cases.  The scope of extensions is not limited to those
> identified by the WIs and WGs, but is limited by the criteria set out below.
>
> 
>
>
>
>
>
> *From:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>
> *Sent:* Monday, November 16, 2020 6:16 PM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>; IETF ALTO 
> *Subject:* RE: ALTO recharter: proposed item - General ALTO protocol
> extensions
>
>
>
> Dear all,
>
>
>
> The paragraph below is proposed to define the WG item on “general protocol
> extensions”.
>
> As the purpose of this work item is also to support other WG items that
> may need these extensions, your feedback again is more than welcome.
>
> Thanks,
>
> Sabine
>
>
>
> General protocol extensions to convey a richer set of cost attributes
> allowing to determine not only "where" and "when" to connect but also under
> which conditions. Such additional information will be related both to
> entities (e.g. conveying time-averaged (cache storage capacities and)
> server load in data center supported applications) and to ALTO path costs
> (e.g. ALTO path cost value depending on conditions such as real-time
> network indications or SLA or policy or access-type or indicator type).
>
>
>
> The working group will specify such extension in coordination with both
> other ALTO working group items and IETF working groups that have a focus on
> the related use cases.  The scope of extensions is not limited to those
> identified by the WIs and WGs, but is limited by the criteria set out below.
>
> 
>
>
>
> *From:* alto  *On Behalf Of *Randriamasy, Sabine
> (Nokia - FR/Paris-Saclay)
> *Sent:* Tuesday, November 1

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

[Y. Richard Yang]

Addressing some comments I received and following the same format as Sabine
did, I post the paragraph below:

Extension of ALTO services to support multi-domain settings. The current
ALTO framework focuses on providing network information from a single ALTO
server for a single network (administrative domain), but the network
devices traversed by a flow can be managed by multiple networks not in the
same domain. The working group will investigate and extend the ALTO
framework to (1) enumerate the issues of ALTO services involving network
paths spanning multiple domains with multiple ALTO servers, and (2)
introduce capabilities to query ALTO services for the settings. The working
group should specify complete ALTO multi-domain services, by using existing
services whenever possible. The working group should consider realistic
complexities including incremental deployment, dynamicity, core security
issues including 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.

Additional info will be discussed in the slides to be discussed in the
weekly meeting tomorrow and then during the meeting later this week.

Any comments are highly welcome.

Richard

On Thu, Nov 12, 2020 at 7:10 PM Y. Richard Yang  wrote:

> Dear ALTOers,
>
> Please see attached an updated version of the slides intended to
> contribute to the multidomain item. The slides are team efforts. Any
> feedback, comments, suggestions are highly welcome. We see that alternative
> designs such as architectures are feasible as well, but we want to post the
> initial design to make clear the problem and feasibility.
>
> Thanks!
> Richard
>
> On Tue, Nov 10, 2020 at 4:12 PM Y. Richard Yang  wrote:
>
>> 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
>>
>

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

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

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

Hello,

Please find below a revision of the proposed definition paragraph.
This WG item is further detailed in the Google doc available here (page 19/25):
https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit

Thanks,
Sabine


General protocol extensions to convey a richer set of attributes allowing to 
determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged server load in data center supported applications) and 
to path costs (e.g. ALTO path cost value depending on conditions such as 
real-time network indications or SLA or policy or access-type or indicator 
type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.



From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Sent: Monday, November 16, 2020 6:16 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

The paragraph below is proposed to define the WG item on "general protocol 
extensions".
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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, 

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

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

Dear all,

The paragraph below is proposed to define the WG item on "general protocol 
extensions".
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.


From: alto  On Behalf Of Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO 
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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

Re: [alto] Meeting info for Nov 17, 2020

[Qin Wu]

Regarding the topic 3, I think investigating the configuration, management, and
operation of ALTO systems is interesting, I am wondering how network topology 
model in RFC8345
and TE topology model in RFC8795 can be translated into network map, property 
map, cost map?

Or use pub/sub mechanism to subscribe specific data source and publish the 
event notification to the ALTO server automatically,
Or translated TEDB and LSPDB directly into Network map or Cost map?

Luis’s draft provide a good use case for this, i.e., automatically derived ALTO 
information from southbound interface.
https://tools.ietf.org/html/draft-contreras-alto-service-edge-02
which also specify additional ALTO protocol extension for computing capability 
exposure and selection.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 kai...@scu.edu.cn
发送时间: 2020年11月16日 21:18
收件人: alto@ietf.org; alto-weekly-meet...@googlegroups.com
主题: [alto] Meeting info for Nov 17, 2020


Dear all,



We will have the last meeting before the IETF 109 ALTO session at 9:00 am US 
EST (3 pm CET, 10 pm Beijing Time).



The purpose is to go over and finalize the recharter items. Given that some 
topics were not presented in the last meeting, I suggest we follow the order 
below:



1. General extensions

2. New transport

3. Operation automation

4. First hop

5. Multi-domain



Bridge: https://yale.zoom.us/my/yryang



Best,

Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO recharter: proposed item - Extends the ALTO Service to provide cellular network Information

[Qin Wu]

Hi, Chunshan:
Thanks for proposed item update, the proposal get polished much better. thanks 
for your good clarification.
I have a few follow up questions below.

发件人: alto [mailto:alto-boun...@ietf.org] 代表 chunshxiong(熊春山)
发送时间: 2020年11月11日 17:13
收件人: alto 
主题: [alto] ALTO recharter: proposed item - Extends the ALTO Service to provide 
cellular network Information

Hello all,

I and Li Gang(China Mobile)  reconstruct the WG item proposal for “Extends the 
ALTO Service to provide cellular network Information” based on the previous 
email and discussion during the weekly meetings.
Welcome your comments.
BRs,
Chunshan Xiong

 Context：Extends the ALTO Service to provide cellular network Information
- Currently ALTO Information Services does not support cellular net.

[Qin]: I am wondering how these cellular network information fit into network 
map, cost map, property map or simply endpoint property, endpoint cost service?
Also I see a lot of relevant work which have been proposed by Sabine in the 
past such as:
https://tools.ietf.org/html/draft-randriamasy-alto-cost-context-01
which also deal with cellular network, specify various different context 
parameter, access technology type,

https://tools.ietf.org/id/draft-randriamasy-alto-mobile-core-01.txt which 
specify 3GPP Cost Map and provide 3GPP User Identification and location
https://tools.ietf.org/id/draft-randriamasy-alto-cellular-adresses-03.txt which 
introduce a new endpoint property
https://tools.ietf.org/id draft-bertz-alto-mobilitynets
It will be great to put them together to take a look at.

1. Problem description
+++ Issue 1: Whether it is feasible to obtain the cellular information?
+++ Issue 2: How does ALTO server obtain cellular information from 5G NEF?
+++ Issue 3：What cellular information is from ALTO server to ALTO client?
+++ Issue 4：What cellular information is exposed from 5G network to ALTO server?


2.Potential solutions and considerations
+++ Solution for Issue 1
   - It is feasible to obtain the cellular information from NEF
   - Reuse the CAPIF defined in 3GPP
   - Leverage the release-17 Edge computing Enhance to provide cellular 
network information wih low-latency.
   [Qin]: I am wondering how section 4.15 of ETSI TS 123 502 is related to 
cellular information retrieval from NEF which specify mobile events and various 
capabilities

https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/15.02.00_60/ts_123502v150200p.pdf
 Is cellular information additional information to mobile events and 
various capabilities exposed by NEF?
+++ Solution for Issue 2:
   - For OB solution, it is proposed that the ALTO server reuses current 
standard to obtain the cellular information via NEF northbound interface.
   - For IB, it is proposed to investigate the potential solution and 
leverage the existing standardization outputs.

+++ Solution for Issue 3:
   - Measurement information: bandwidth, latency, jitter
   - Predicted information: available bandwidth for next a few seconds
  [Qin]: I think all of these are cost metric information which are part of 
cost map, is there any endpoint property information? E.g, from UE to Cell, or 
from cell to another cell?
+++ Solution for Issue 4:
   - Radio channel status: e.g. SINR, RSRP/RSRQ, CQI, MCS
   - L2 user plane measurements: e.g. thoughtputthroughput, latency
  [Qin]: Again, it is not clear whether it is end to end QoS network 
performance from source to destination or network performance from one edge to 
another edge? From UE to Cell or from UE to the Edge?
   - In addition, different levels can also be considered, i.e. flow, UE, 
slice, serving cell and neighboring cell. For those information defined but not 
exposed from 5G network, we can send LS to 3GPP to ask for such information 
exposure.
  [Qin]: Can you confirmation whether those information contain Radio 
channel status or L2 user plane measurement information.
3.   Remaining issues to be addressed
+++ Security/sensitivity of info
   - It is not sensitive for OB solution and
   - for future study for IB.
   - For OB+IB solution defined in 3GPP EC in Rel-17, it is treated as 
OB solution for IETF ALTO.

+++  Given 3GPP/layer 2 SDO are defining this interface/service, why do we need 
ALTO to do it as well? Why Internet standard, and 3GPP standards are not enough?
   - 3GPP NEF provides low layer information, which is hard for application 
usage directly.
   - ALTO server can aggregate such original cellular information, and have 
capability and possibility to process that information and provide it to 
applications (ALTO client) with more easy to use via a single interface.
 [Qin]: Good point.
+++ Is the info really useful?
   - The results from IETF MOWIE draft paper can prove the benefit of 
utilizing such cellularinformation.  -

+++ Are the providers willing to provide the info?
   - It depends on

[alto] Meeting info for Nov 17, 2020

[kaigao]

Dear all,




We will have the last meeting before the IETF 109 ALTO session at 9:00 am US 
EST (3 pm CET, 10 pm Beijing Time).




The purpose is to go over and finalize the recharter items. Given that some 
topics were not presented in the last meeting, I suggest we follow the order 
below:




1. General extensions

2. New transport

3. Operation automation

4. First hop

5. Multi-domain




Bridge: https://yale.zoom.us/my/yryang




Best,

Kai___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto