Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail)

[熊春山]

Hello all,

@Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay),  You say “An 
ALTO Server cannot provide real-time information".
I almost agree with your point.

But I want the ALTO Server to support very quick notification information to 
the ALTO Client, if there is a quick change as provided in my other email.

I think one goal of ALTO Server is not to  provide very frequent notification 
to the ALTO Client, but If there is some quick or big change, the ALTO Server 
needs very quickly notify the ALTO Client, just this, not repeated and 
continuous notify. I think this quick notification is very helpful for the 
cloud gaming server to adaptive change the coding scheme. But the cloud gaming 
does not need the ALTO server to repeated notify the current network bitrates. 
Cloud gaming server needs the change information not the status information. 
For the cloud gaming sever can “intelligently” detect the slow change 
information, but it is very hard for the gaming server to detect the quick 
change in short time (because there is buffer in the client and Server), in 
such case, if the ALTO server can provide such quick (QoS) change information 
to the cloud gaming server, the cloud gaming server can quickly change its 
coding scheme.

So, Yes, the cloud gaming server does NOT need the real-time QoS information, 
but the cloud gaming server does need the real-time QUICK QOS CHANGE 
information.

But, this Quick QoS change (e.g. Alternative QoS profile) is defined to trigger 
the cloud server to make some changes(e.g. encoding scheme change).  It should 
be avoid to define a  QUICK QOS change that does not trigger the cloud server 
to make any changes. So the real-time frequently reporting the current QOS to 
the cloud server is really not needed,  this repeated and continuous 
reporting/notification only creates a lot of message loads and no help for the 
cloud gaming server.

Also this Quick QoS Change notification should not be too frequent, the QUICK 
QoS change notification should be minutes level, i.e. one notification per one 
minute. In some cases, it is possible that the notification can be several 
notifications per one minutes, but the average rate should be less than one 
notification per one minute.


BRs,
Chunshan Xiong

From: alto  On Behalf Of Y. Richard Yang
Sent: Friday, March 12, 2021 5:29 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: alto-cha...@ietf.org; alto-...@ietf.org; Qin Wu ; IETF 
ALTO 
Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes(Internet mail)

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look at 
the design in a slightly abstract, general framework. In particular, the 
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small, 
fast-changing data;
- Vs: Another set of records that are stable and indexed by the ephemeral 
variables; Vs can be large, but stable data.

There are two channels from the network to the application:
- Channel 1 for Ve
- Channel 2 for Vs

This definitely is a generic framework supported by some existing use cases 
including what you presented.

In the general framework, Channel 1 can be ALTO or protocol specific. Since it 
is short and needs low latency, it is more likely to be protocol specific and 
embedded in some other protocol such as even data path protocols (5G, ECN bits 
in IP); channel 2 is ALTO.

A couple of points to be considered when conducting further design:
- One thing we learned from SSE is the consistency between these two channels 
(or more, as Ve can be carried by multiple channels, etc), and
- Document additional use cases beyond the demonstrated use cases.

Looking forward to talking to you (virtually) f2f tomorrow.

Richard

On Thu, Mar 11, 2021 at 5:01 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu mailto:bill...@huawei.com>>
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO 

Re: [alto] qoRE: Pub/sub thread; Was Re: ALTO Draft ReCharter WG review(Internet mail)

[熊春山]

Hello Richard,

Yes, the two use cases can be use the same “sub/pub” mechanism to subscribe the 
requirement to the ALTO Server and the ALTO Server can notify the (quick) 
change of the bitrate/latency of network to the ALTO Client.

I just use “sub/pub” to demonstrate the procedures to “request “ and “notify” , 
how to support these procedures with current protocol if the current protocol 
can support these procedure  or whether new protocol should be defined to 
support need to be identified ?

We do not need re-invent the wheel, but if the current tools can not support 
the use cases, we need to define new protocol.


BRs,
Chunshan

From: Y. Richard Yang 
Sent: Friday, March 12, 2021 3:55 AM
To: chunshxiong(熊春山) 
Cc: Li Gang ; alto-cha...@ietf.org; 
alto-...@ietf.org; Kai Gao ; Qin Wu ; 
IETF ALTO 
Subject: Re: qoRE: [alto] Pub/sub thread; Was Re: ALTO Draft ReCharter WG 
review(Internet mail)

Hi Chunshan,

Thanks a lot for the clarification. Please see below.

On Wed, Mar 10, 2021 at 2:31 AM chunshxiong(熊春山) 
mailto:chunshxi...@tencent.com>> wrote:
Hello all,

There are a lot of interesting discussion on the “pub/sub” related use cases 
and mechanisms.

Here I want to provide some use cases on how the “pub/sub” needs to support:


1) One sub/pub for different bitrates :

e.g.  the alto client can subscribe the alto server to get 5G network current 
supporting bitrates as :

a) bigger than  A kbps;

b) less than A but bigger than B;

c) less than B;

where A>B, e.g. A is for 1080p video streaming, B is for 720p streaming,

of course, we can introduce more different bitrates span, but for simple, only 
3 are defined in the example.



In such case the alto server will pub(notify) the alto client the current 5G 
network bitrates when the bitrates span is changed (not the bitrates are 
changed, only after the bitrate changed into different bitrate span).

It is each to above bitrates to latency.
This is a good use case. It is essentially a dampening mechanism to reduce the 
load on the (server-client) push channel.

Another related comment is that I may need to finalize the term for this type 
of communication. It may not be pub/sub, but something different. Traditional 
ALTO request-response (without SSE) is a "simple" request-response, in which 
the client sends a request, the server receives the request, generates a 
response, and sends the response back to the client; the connection is 
conceptually closed. Your setting is an example that is getting closer to a 
more general "RPC" model, for example, the protocol buffer model 
(https://developers.google.com/protocol-buffers/docs/reference/proto3-spec):

service = "service" serviceName "{" { option | rpc | emptyStatement } "}"
rpc = "rpc" rpcName "(" [ "stream" ] messageType ")"
  "returns" "(" [ "stream" ] messageType ")"
   (( "{" {option | emptyStatement } "}" ) | ";")

It looks that you are asking to add the "stream" in return.


2) Normally, the smart UE-client and cloud Server application can use the 
adaptive bitrate changes to handle the network bitrate changes as above, but 
there are still a lot of chances that the client application temporary halts to 
wait the downlink data in the cloud gaming. Because in some case the bitrates 
of the 5G RAN change very quicky and steeply in a short time and the ALTO 
server can not in time to provide such information to the alto client.

In order to handle such steeply and quickly bitrate changes in the wireless 
system, a new sub/pub use case is needed as below.

The alto client can subscribe the ALTO server to notify the Quick QoS Change. 
E.g. if the bitrate decreases/increases  30% (e.g. changes +- 30%) （ or 
decreases/increases  A kbps） in a short time ，the alto serve shall notify the 
alto client very quickly and emergently.

(Normally, if the bitrates changes  up and down very quickly but the average 
bitrate are not changed, it is not considered as the QUICK QOS Change. The 
QUICK QoS Change means the bitrates are changed quickly and steeply in short 
time and keeps the new bitrates  after the QUICK change).

With such QUICK QoS Change sub/pub, the cloud gaming server can real-time to 
get the 5G network bitrates big changes and quickly use the adaptive encoding 
scheme.
What is the differences between the above 1) and 2) ?
Normally the 1) needs the alto client to provides the bitrates spans to the 
alto server and 5G network , and 5G network or the alto server  needs to 
compare its current bitrates with the provided bitrate span. But for the 2) the 
alto client does not provide any defined bitrate values, it only provides the 
bitrate change ratio or change values to the alto server and 5G, then the 5G 
network or the alto server needs to compare the bitrate changes and notify the 
alto client.

1) is well defined in 3GPP for 5G standards, but this method is used only 
for the Guaranteed QoS Flow (currently, the Guaranteed  QoS Flow is used by is 
not used very widely, 

Re: [alto] ALTO Draft ReCharter WG review

[刘鹏]

Hi Richard,




Thanks for sharing your idea！ I think it's necessary to considering the 
security and privacy issues.




The framework of differential privacy can be a potential choice to protect 
individual or detail privacy of network without encryption which might influent 
the efficiency of information exchange, while it need to consider the data 
availability.




Regards,

Peng








Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  liupeng...@chinamobile.com

 



发件人: Y. Richard Yang

时间: 2021/03/10(星期三)10:32

收件人: Qiao Xiang;

抄送人: 刘鹏;IETF ALTO;Qin Wu;

主题: Re: [alto] ALTO Draft ReCharter WG review



Hi Peng, all,




Thanks a lot for the excellent discussions. It is clear that multi-domain is a 
major issue to resolve, as multidomain is the general deployment setting where 
resource consumers and providers are in the general case deployed in multiple 
networks. 




To proceed with the recharter discussion, I suggest that we conduct basic 
security and privacy analysis to see if we are ready for recharter; that is, we 
have a basic understanding of related issues so that it is ready for design, 
not still in the early research stage. For security, we can start with focusing 
on the basic requirements including authenticity, integrity, and 
confidentiality. For privacy, we can start with a framework such as 
differential privacy analysis.




To me, a basic model of a multi-domain alto information service is the 
following:

- a set of (potential) resource providers s1, s2, ..., 


- a set of (potential) resource consumers c1, c2, c3, ...






The foundation of the alto service is to provide the costs of the paths {si -> 
cj}; I always think of alto as an extension of DNS, which is mainly for 
endpoints in a graph and alto is paths. In a single domain setting, all 
entities, {si}, {cj}, {si->cj} are within a single domain and hence the main 
security/privacy issue is the security/privacy issue of between the single alto 
server representing the single domain and the alto client. For security, the 
domain can leverage any one of the security systems (e.g., using public keys to 
bootstrap the system); for privacy, the application (client) and the network 
(server) are two parties, and they can agree on an acceptable privacy model.




Now, in a multi-domain setting, each entity may have a different domain (or a 
sequence of domains for a path). Now, both ALTO client and ALTO server will 
have additional security and privacy issues. 

- For the ALTO client, the information can now come from multiple networks; 
assume the information info(n1, n2, ...)  is computed from those from multiple 
networks n1, n2, ... Then the basic security issue is how the client can verify 
the authenticity of the information. 

- For an ALTO server, the server may not have a direct trust relationship with 
the client; for example, when the ALTO server is only in the chain of a path, 
not the client-facing server. Hence, the server may not have a relationship to 
specify the privacy requirement.




The preceding are challenging issues. It is clear that security and privacy 
issues depend on the specific design. Hence, we target a "lower-bound" 
analysis, by considering a base design that can address main security and 
privacy issues. The WG can decide on the specific design which is better than 
the basic design.








During the design meetings, we have considered the following "base-line" design 
for a "lower-bound":

-  We provide a basic path discovery service to discover the path segments. We 
can use BGP security to bootstrap the security of the discovered paths. 

- We build verifiable aggregation (i.e., the preceding info function) so that 
the information can then be individually verified. 

- The remaining issue is how each server can control the privacy of its 
information, as it may not have a direct relationship with the client. For 
this, we suggest to start with basic public information, and gradually build 
trust.




The preceding is high level. A first task, if multidomain is charted, is to 
write down the details, beyond the existing drafts. I do agree that this 
analysis and requirements is a good starting, based on the specified use cases.




We can go over the details in our design meeting in the next few following 
weeks.




Richard




 













On Tue, Mar 2, 2021 at 11:18 AM Qiao Xiang  wrote:




Hi Peng, Qin and Richard,




Very good discussion! Richard and I have been working with folks from CMS and 
ESNet (a large global multi-domain science network) to design network 
information exposure abstractions and mechanisms in multi-domain networks, with 
privacy requirements considered. The basic idea stems from the ALTO path-vector 
extension but goes beyond to take privacy into consideration. The following are 
some pointers.


[1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network 
Resource Discovery", IEEE JSAC, 2019. 

[alto] Status of chartered WG items

[Vijay Gurbani]

All: Since we have only one hour on Fri for our meeting, I am summarizing
the status of the existing chartered items on the list.  Hopefully, we can
spend no more than 2s on the corresponding chair slides in the meeting
tomorrow.

draft-ietf-alto-unified-props-new and draft-ietf-alto-path-vector have been
reviewed by me (as chair and shepherd).  The shepherd writeup has been
shared on the mailing list for each of these.  The token is with me as the
shepherd to make sure all comments are attended to in the revisions and
then move them to IESG.  I should do this after the current IETF.

draft-ietf-alto-performance-metrics is being shephereded by Jan. IPR check
has been done and I believe that Jan needs to complete the shepherd writeup
and draft review.  Version -15 was released on 2021-02-04 and addresses
comments and issues from WGLC.

draft-ietf-alto-cdni-request-routing-alto is ready to go and I will be
posting the shepherd writeup on the list next week.  The draft is ready and
mature and has been socialized broadly.

unified-props, path-vector, and cdni-request-routing will be moved ahead as
a cluster since the latter two have a dependency on unified-props.

To save time during tomorrow's meeting, please post to the list if you have
any questions.

Thanks,

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

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

[Y. Richard Yang]

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look
at the design in a slightly abstract, general framework. In particular, the
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small,
fast-changing data;
- Vs: Another set of records that are stable and indexed by the
ephemeral variables; Vs can be large, but stable data.

There are two channels from the network to the application:
- Channel 1 for Ve
- Channel 2 for Vs

This definitely is a generic framework supported by some existing use cases
including what you presented.

In the general framework, Channel 1 can be ALTO or protocol specific. Since
it is short and needs low latency, it is more likely to be protocol
specific and embedded in some other protocol such as even data path
protocols (5G, ECN bits in IP); channel 2 is ALTO.

A couple of points to be considered when conducting further design:
- One thing we learned from SSE is the consistency between these two
channels (or more, as Ve can be carried by multiple channels, etc), and
- Document additional use cases beyond the demonstrated use cases.

Looking forward to talking to you (virtually) f2f tomorrow.

Richard

On Thu, Mar 11, 2021 at 5:01 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Qin,
>
>
>
> Please see inline,
>
> Thanks
>
> Sabine
>
>
>
> *From:* Qin Wu 
> *Sent:* Thursday, March 11, 2021 9:32 AM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>; IETF ALTO 
> *Cc:* alto-cha...@ietf.org; alto-...@ietf.org
> *Subject:* RE: ALTO Draft ReCharter WG review - extensible set of policy
> attributes
>
>
>
> Hi, Sabine:
>
> *发件人**:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) [
> mailto:sabine.randriam...@nokia-bell-labs.com
> ]
> *发送时间**:* 2021年3月11日 1:55
> *收件人**:* Qin Wu ; IETF ALTO 
> *抄送**:* alto-cha...@ietf.org; alto-...@ietf.org
> *主题**:* RE: ALTO Draft ReCharter WG review - extensible set of policy
> attributes
>
>
>
> Hello ALTO WG,
>
>
>
> Regarding the proposed work item on “Protocol extensions to support a
> richer and extensible set of policy attributes in ALTO information update
> request and response” (GPE for short) , I would like to add the following:
>
>
>
> This work item can be useful, among others, to allow a UE getting cellular
> network KPIs from an ALTO Server, to figure out for example whether the
> cell is congested, or which cell to choose.
>
>
>
> An ALTO Server cannot provide real-time information. With the proposed
> extensions, it can indicate a number of real-time network parameters
> against which ALTO cost values can be modulated.
>
>
>
> [Qin]: Yes, the current ALTO server can only provide non-real time or near
> real time information, performance metrics work allows ALTO server expose
> performance data. If ALTO protocol is extended to support pub sub mechanism,
>
> Providing real time information will not be an issue.
>
>
>
> But I agree in many cases, providing real time information is not
> necessary, e.g., cloud gaming use case provided Tencent and china mobile,
> their case is different from your proposed case, they will use cloud gaming
> server as ALTO client to get needed information.
>
> *[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially
> integrated with a cloud gaming server (CGS for short) . In that case, the
> ALTO information provided by the ALTO Server (AOS for short) can be made
> aware of given specific parameters captured by the CGS at a different pace.
> This may speed up the process as well.  *
>
>
>
> These parameters are received by UEs directly from the network and not
> from ALTO. The UE receives an array of ALTO cell KPI values that each
> depend on the value of a parameter. The UE can pick the  ALTO value
> corresponding to the value of the real-time parameter received from the
> network. Thus, the UE modulates the received ALTO values in real-time.
>
>
>
> [Qin]: your case is UE centric solution, UE gets network KPI from ALTO
> server and get real time parameter from another data source in the Network,
> what is not clear is how real time parameter is correlated with Network KPI
> information within UE.
>
> Also the interface between UE and RAN is not in the scope of ALTO work, I
> think.
>
> *[ [SR] ] definitely, the scope of the extension restricts to exchanges
> between AOS and AOC. The UE may have some agent that gathers and relates
> the RAN indicators and the ALTO information and passes the relevant costs
> to the application client. Again this agent is out of scope of ALTO. *
>
>
>
> This use-case is illustrated in the slides presented at the previous IETF
> 109 ALTO WG meeting, see (1), slide 4. A preliminary design with example
> IRD and ALTO request and response can be found in slides 7 and 8.
>
>
>
> Any feedback is more than welcome,
>
> (1)
> 

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

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

Hi Vijay,

Thanks again for your revision of version 15.
I still owe to you and the WG an inline response by Jensen and myself to your 
comments.
For the moment, I have the attached text file that integrates them with your 
comments.
Most of your comments were hopefully correctly addressed and we still have 
thoughts on comments regarding sections:
4.7.1, 4.4.3, 9.3, 11.
I will send an “integrated” response tomorrow to the list.
Thanks,
Sabine


From: Vijay Gurbani 
Sent: Saturday, February 27, 2021 9:18 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: alto@ietf.org
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

Dear Sabine: Thank you.  I will look over the changes and move the draft ahead.
I plan to do so next week.
- vijay

On Mon, Feb 22, 2021 at 6:49 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Dear all,

This version 16 addresses most of Vijay's review comments part 1 and 2.
We will come back in a few days with details on how the comments have been 
addressed.
Thanks,
Sabine

>-Original Message-
>From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
>internet-dra...@ietf.org
>Sent: Tuesday, February 23, 2021 1:01 AM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Application-Layer Traffic Optimization WG of 
>the
>IETF.
>
>Title   : ALTO extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-16.txt
>   Pages   : 57
>   Date: 2021-02-22
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   as applied to endpoints as defined by IP addresses to endpoints
>   defined by a wider set of objects.  Further, these properties are
>   presented as maps, similar to the network and cost maps in the base
>   ALTO protocol.  The protocol is extended in two major directions.
>   First, from endpoints restricted to IP addresses to entities covering
>   a wider and extensible set of objects; second, from properties on
>   specific endpoints to entire entity property maps.  These extensions
>   introduce additional features allowing entities and property values
>   to be specific to a given information resource.  This is made
>   possible by a generic and flexible design of entity and property
>   types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at 
>tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
=== Chair review of unified-props (Part 1 of 2) ===

Major:

- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match.  Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects.  Further, these properties are presented
as maps, similar to the network and cost maps in 

Re: [alto] qoRE: Pub/sub thread; Was Re: ALTO Draft ReCharter WG review(Internet mail)

[Y. Richard Yang]

Hi Chunshan,

Thanks a lot for the clarification. Please see below.

On Wed, Mar 10, 2021 at 2:31 AM chunshxiong(熊春山) 
wrote:

> Hello all,
>
>
>
> There are a lot of interesting discussion on the “pub/sub” related use
> cases and mechanisms.
>
>
>
> Here I want to provide some use cases on how the “pub/sub” needs to
> support:
>
>
>
> 1) One sub/pub for different bitrates :
>
> e.g.  the alto client can subscribe the alto server to get 5G network
> current supporting bitrates as :
>
> a) bigger than  A kbps;
>
> b) less than A but bigger than B;
>
> c) less than B;
>
> where A>B, e.g. A is for 1080p video streaming, B is for 720p streaming,
>
> of course, we can introduce more different bitrates span, but for simple,
> only 3 are defined in the example.
>
>
>
> In such case the alto server will pub(notify) the alto client the current
> 5G network bitrates when the bitrates span is changed (not the bitrates are
> changed, only after the bitrate changed into different bitrate span).
>
> It is each to above bitrates to latency.
>
This is a good use case. It is essentially a dampening mechanism to reduce
the load on the (server-client) push channel.

Another related comment is that I may need to finalize the term for this
type of communication. It may not be pub/sub, but something different.
Traditional ALTO request-response (without SSE) is a "simple"
request-response, in which the client sends a request, the server receives
the request, generates a response, and sends the response back to the
client; the connection is conceptually closed. Your setting is an example
that is getting closer to a more general "RPC" model, for example, the
protocol buffer model (
https://developers.google.com/protocol-buffers/docs/reference/proto3-spec):

service = "service" serviceName "{" { option | rpc | emptyStatement } "}"
rpc = "rpc" rpcName "(" [ "stream" ] messageType ")"
  "returns" "(" [ "stream" ] messageType ")"
   (( "{" {option | emptyStatement } "}" ) | ";")

It looks that you are asking to add the "stream" in return.

2) Normally, the smart UE-client and cloud Server application can use
> the adaptive bitrate changes to handle the network bitrate changes as
> above, but there are still a lot of chances that the client application
> temporary halts to wait the downlink data in the cloud gaming. Because in
> some case the bitrates of the 5G RAN change very quicky and steeply in a
> short time and the ALTO server can not in time to provide such information
> to the alto client.
>
> In order to handle such steeply and quickly bitrate changes in the
> wireless system, a new sub/pub use case is needed as below.
>
> The alto client can subscribe the ALTO server to notify the Quick QoS
> Change. E.g. if the bitrate decreases/increases  30% (e.g. changes +- 30%)
> （ or decreases/increases  A kbps） in a short time ，the alto serve shall
> notify the alto client very quickly and emergently.
>
> (Normally, if the bitrates changes  up and down very quickly but the
> average bitrate are not changed, it is not considered as the QUICK QOS
> Change. The QUICK QoS Change means the bitrates are changed quickly and
> steeply in short time and keeps the new bitrates  after the QUICK change).
>
> With such QUICK QoS Change sub/pub, the cloud gaming server can real-time
> to get the 5G network bitrates big changes and quickly use the adaptive
> encoding scheme.
>
> What is the differences between the above 1) and 2) ?
>
> Normally the 1) needs the alto client to provides the bitrates spans to
> the alto server and 5G network , and 5G network or the alto server  needs
> to compare its current bitrates with the provided bitrate span. But for the
> 2) the alto client does not provide any defined bitrate values, it only
> provides the bitrate change ratio or change values to the alto server and
> 5G, then the 5G network or the alto server needs to compare the bitrate
> changes and notify the alto client.
>
> 1) is well defined in 3GPP for 5G standards, but this method is used
> only for the Guaranteed QoS Flow (currently, the Guaranteed  QoS Flow is
> used by is not used very widely, currently it is only used by the
> operator’s HD Voice (i.e. Voice Over LTE/5G, i.e. Voice over IMS) service
> ); 2) can be used by the Guaranteed QoS Flow and non-Guaranteed QoS Flow
> (the Non Guaranteed QoS Flow is widely used by the internet applications ).
> We/Tencent are going to study the 2) and try to find out how much QoE
> improvement based on this Quick QoS Change. We/Tencent also are planning to
> push 3GPP 5G to study this Quick QoS Change standards in Release 18.
>

Thank you for clarifying these two different use cases.

My first reaction is that regardless of which use case, they are good use
cases supporting the ALTO mission: network providing information that the
clients may not easily get by themselves. The wireless channels are
complex, expensive, shared channels. It is a location where the network
(ALTO) server can 

[alto] Jabber monitor and note takers needed

[Vijay Gurbani]

All: ALTO WG meeting is on Fri.

Please send an email to the chairs if you would like to volunteer for
taking notes and monitoring Jabber.

Thanks,

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

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

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

Hi Qin,

To my knowledge, ALTO is not expected to provide real-time information.
On the other hand is it very useful to convey abstracted information covering 
cellular networks and beyond, starting with edge.
So an ALTO Server may want to approach real-time information but cannot commit 
to it.
This all depends on the covered network scope and level of network information 
aggregation or abstraction and other factors that may be looked at within the 
scope of the ALTO operation automation WI.
To help an ALTO Client needing near-instant information, the ALTO Server may 
indicate the available levels of information “freshness” or  length of validity 
intervals with policy attributes that can be used by the Client in its ALTO 
request.

Sabine


From: Qin Wu 
Sent: Thursday, March 11, 2021 11:41 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Cc: alto-cha...@ietf.org; alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Sabine:
Thanks for your clarification, I want to make sure the ALTO clients can express 
to the ALTO sever that they want real time data or not real time data. Also 
Alto server can express that the returned  information is real time or not real 
time in the response message to the ALTO clients.
Are these covered by your case as well?

_Qin
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 18:01
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu mailto:bill...@huawei.com>>
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.
[ [SR] ] definitely, the scope of the extension restricts to exchanges between 
AOS and AOC. The UE may have some agent that gathers and relates the RAN 
indicators and the ALTO information and passes the relevant costs to the 
application client. Again 

Re: [alto] Bringing operation automation cases to the list

[kaigao]

Hi all,




Below are some thoughts on the overlay/underlay integration discussion. Please 
see details inline.




Kai



-Original Messages-
From:"Qin Wu" 
Sent Time:2021-03-11 15:55:31 (Thursday)
To: "Jensen Zhang" 
Cc: "alto@ietf.org" 
Subject: Re: [alto] Bringing operation automation cases to the list



Hi, Jensen:

发件人: Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
发送时间: 2021年3月11日 15:39
收件人: Qin Wu 
抄送: Y. Richard Yang ; LUIS MIGUEL CONTRERAS MURILLO 
; alto@ietf.org
主题: Re: [alto] Bringing operation automation cases to the list

 

Hi all,

 

Please see my comments inline.

 

 

On Thu, Mar 11, 2021 at 2:38 PM Qin Wu  wrote:

Hi, Richard:

发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang
发送时间: 2021年3月11日 12:52
收件人: LUIS MIGUEL CONTRERAS MURILLO 
抄送: alto@ietf.org
主题: Re: [alto] Bringing operation automation cases to the list

 

Hi Luis,

 

Good summary. Please see below.

 

On Wed, Mar 10, 2021 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO 
 wrote:

Hi all,

 

Apologies for the time taking to post the operation automation cases to the 
list.

 

As part of the re-charter discussion, four use cases will be considered for 
supporting the proposal in which respect to ALTO extensions for operation 
automation.

 

Case 1. Extensions to RFC 7971 leveraging on previous protocol extensions 
(e.g., cost calendar, path vector) that can make necessary new architectural 
and deployment considerations

  

RFC7971 is valuable and hence an update to include the effects of protocol 
extensions is highly valuable. I understand that cost calendar and path vector 
are examples, and other extensions such as SSE can be included and we want to 
make sure to do a relatively comprehensive update.

[Qin]: Another limitation of RC7971 is to lack multi-domain support. Therefore 
I feel multi-domain support should be also documented for this item to address 
limitation of ALTO deployment in RFC7971.

 

Yes, multi-domain support can be also considered. But we need to clarify the 
limitation of existing deployment considerations for multiple-domain cases in 
RFC7971 (e.g., cascaded servers). To compare with the well-specified extensions 
like cost calendar, path vector, and SSE, one concern is that the multi-domain 
support may involve new extensions which have not been well specified yet.

 

[Qin]: Good point, this is chicken-egg problem.:-)

Case 2. Usage of ALTO for combined compute and network selection (e.g., for 
optimal edge computing service placement).

 

Does Case 2 belong to general protocol extension or operation automation?

[Qin]:I think operation automation is also required  in this case, i.e., how 
network information and compute information are aggregated. One thing I am not 
sure is whether

Whether path vector has already supported compute information? Maybe author can 
clarify.

 

The path vector extension itself doesn't support compute information. I assume 
you are talking about the entity property map. I think we can leverage the 
entity property map to expose the compute information by defining new entity 
domains and property types systematically (like what the performance cost 
metrics document does). But we need to dig into real use cases to see if 
anything is missing.

 

But beyond the protocol extension, I'm also interested in how to collect those 
compute information from an operator's view. It will also affect the data model 
work.

[Qin]: IETF Dyncast side meeting last night investigate what metric should be 
defined, how frequent the update is, I think probably also related to this 
issue. I think ALTO can provide a solution for compute information exposure if 
we look for centralized solution.

 

Case 3. Extensions to ALTO for acting as aggregator of information from 
different sources (e.g., TEDB, LSP DB, etc)

 

Case 3 is definitely a good use case supporting operation automation.

 

Case 4. Overlay / underlay integration supported by ALTO (e.g., CDN).


Overlay/underlay integration can have many aspects. So the goal is to focus on 
the operation automation aspect? One possibility is to define operation 
automation broadly, including operation automation of not only ALTO but the 
overall system (i.e., the integrated overlay/underlay). If this is the case, we 
may want to specify the scope well.

[Qin]: Agree, I think this case describe ALTO interface as Network as a service 
interface, allow the underlay expose capability and status to the overlay, So 
overlay can know how to optimize the service delivery. This case looks very 
interesting.

 

I think not just the underlay can expose info to the overlay, the overlay can 
also express its fine-grained demand and subscribe info to the underlay. It may 
have some overlaps with the pub/sub item. We may need more clarification about 
the integration solution.




[KAI] When Jensen said "overlaps with the pub/sub item", my understanding is 
that the integration is a closed-loop such that the overlay may alter 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

[Qin Wu]

Sabine:
Thanks for your clarification, I want to make sure the ALTO clients can express 
to the ALTO sever that they want real time data or not real time data. Also 
Alto server can express that the returned  information is real time or not real 
time in the response message to the ALTO clients.
Are these covered by your case as well?

_Qin
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 18:01
收件人: Qin Wu ; IETF ALTO 
抄送: alto-cha...@ietf.org; alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu mailto:bill...@huawei.com>>
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.
[ [SR] ] definitely, the scope of the extension restricts to exchanges between 
AOS and AOC. The UE may have some agent that gathers and relates the RAN 
indicators and the ALTO information and passes the relevant costs to the 
application client. Again this agent is out of scope of ALTO.

This use-case is illustrated in the slides presented at the previous IETF 109 
ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and 
ALTO request and response can be found in slides 7 and 8.

Any feedback is more than welcome,
(1)  
https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00
Thanks,
Sabine



From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Qin Wu
Sent: Monday, February 22, 2021 2:51 PM
To: IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: [alto] ALTO Draft ReCharter WG review

Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 
110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents 
in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been 
posted to this list,

This charter has received a couple of 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

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

Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu 
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Cc: alto-cha...@ietf.org; alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.
[ [SR] ] definitely, the scope of the extension restricts to exchanges between 
AOS and AOC. The UE may have some agent that gathers and relates the RAN 
indicators and the ALTO information and passes the relevant costs to the 
application client. Again this agent is out of scope of ALTO.

This use-case is illustrated in the slides presented at the previous IETF 109 
ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and 
ALTO request and response can be found in slides 7 and 8.

Any feedback is more than welcome,
(1)  
https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00
Thanks,
Sabine



From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Qin Wu
Sent: Monday, February 22, 2021 2:51 PM
To: IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: [alto] ALTO Draft ReCharter WG review

Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 
110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents 
in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been 
posted to this list,

This charter has received a couple of rounds of informal review from WG 
members, chairs and our Ads from brief to deep thorough, 5 new chartered items 
have been listed.
We would like to solicit feedback on these new chartered items and your use 
case, deployment, idea corresponding to these new chartered items.
Sharing your past deployment story will also be appreciated.


The ALTO working group was established in 2008 to devise a request/response 
protocol to allow a host to benefit from a server that is more cognizant of the 
network infrastructure than the host is.

The working group has developed an HTTP-based protocol and recent work has 
reported large-scale deployment of ALTO based solutions 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

[Qin Wu]

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu ; IETF ALTO 
抄送: alto-cha...@ietf.org; alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.

This use-case is illustrated in the slides presented at the previous IETF 109 
ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and 
ALTO request and response can be found in slides 7 and 8.

Any feedback is more than welcome,
(1)  
https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00
Thanks,
Sabine



From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Qin Wu
Sent: Monday, February 22, 2021 2:51 PM
To: IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: [alto] ALTO Draft ReCharter WG review

Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 
110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents 
in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been 
posted to this list,

This charter has received a couple of rounds of informal review from WG 
members, chairs and our Ads from brief to deep thorough, 5 new chartered items 
have been listed.
We would like to solicit feedback on these new chartered items and your use 
case, deployment, idea corresponding to these new chartered items.
Sharing your past deployment story will also be appreciated.


The ALTO working group was established in 2008 to devise a request/response 
protocol to allow a host to benefit from a server that is more cognizant of the 
network infrastructure than the host is.

The working group has developed an HTTP-based protocol and recent work has 
reported large-scale deployment of ALTO based solutions supporting applications 
such as content distribution networks (CDN).

ALTO is now proposed as a component for cloud-based interactive applications, 
large-scale data analytics, multi-cloud SD-WAN deployment, and distributed
computing. In all these cases, exposing network information such as abstract 
topologies and network function deployment location helps applications.

To support these emerging uses, extensions are needed, and additional 
functional and architectural features need to be considered as follows:

o Protocol extensions to support a richer and extensible set of policy 
attributes in ALTO information update request and response. Such policy 
attributes may indicate information dependency (e.g., ALTO path-cost/QoS 
properties with dependency on real-time network  indications), optimization 
criteria (e.g., lowest latency/throughput network performance objective), and 
constraints (e.g., relaxation bound of optimization criteria, domain or network 
node to be traversed, diversity and redundancy