Re: [alto] WG Review: ALTO Charter Update(Internet mail)

[熊春山]

Hello Qin,

Thanks for the feedback!

Regarding to the recharter proposal, we attended the discussion quite long time 
(though quite a lot are not the WG level but within design team).  The bullet 
you referenced indeed in our view is just for information and may not end up 
with a WG document.  So this is indeed not our expectation:-)

o Report back to the Area Director to identify any use cases that have strong 
support and a realistic chance of implementation and deployment.

So, regarding to your proposal to spit into different documents, thanks for the 
proposal but we will evaluate and discuss within design team and decide whether 
to continue.

Meanwhile, for coordination between 3GPP and IETF, indeed there is official 
LSes always between these two SDOs, but the LS normally is based on the 
progress on standards work related to each other. The ongoing 3GPP R-18 new 
study/work item selection sees great interest in ( interactive) application 
network coordination for different kinds of companies. If IETF ALTO does not 
continue to study the new protocol to support the new services, even if 3GPP 
sends LS to IETF, we may not be able to address it properly.
In 3GPP Rel-17, 44 companies from global area support advanced interactive 
services related work ranked as high priority topic during work item 
prioritization.   From a service provider perspective, it is also very clear to 
us how important it is to optimize the user experiences for such important and 
popular scenarios like cloud gaming etc.  It is really a pity that some of the 
interested companies may not come to IETF but it really doesn’t mean such use 
case are not dominant.  In future we can consider to ask more companies to come 
to IETF or ask their 3GPP team to align with IETF team:-)  Regarding to new 
wheels, we think there is very clear spit/boundary between 3GPP and IETF thus 
such cases can probably be avoided easily.  Anyway, this is something in the 
future and we can come to IETF when proper.

So, again thanks for Qin’s response and we do hope ALTO  is actually addressing 
how state-of -the-art dominating application and network can coordinate to 
improve user experiences.

Thanks a lot!

BRs,

Chunshan Xiong

From: Qin Wu 
Sent: Wednesday, May 12, 2021 8:14 PM
To: chunshxiong(熊春山) ; IETF ALTO 
Cc: alto-cha...@ietf.org; Zaheduzzaman Sarker 
Subject: RE: [alto] WG Review: ALTO Charter Update(Internet mail)

Thanks Chunshan for your input and comments on charter proposal, see reply 
inline.
发件人: chunshxiong(熊春山) [mailto:chunshxi...@tencent.com]
发送时间: 2021年5月11日 16:40
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; Zaheduzzaman Sarker 
mailto:zaheduzzaman.sar...@ericsson.com>>
主题: RE: [alto] WG Review: ALTO Charter Update(Internet mail)

Hello WuQin and working group,

I provide our views on this recharter.

Firstly, we think ALTO is an IETF WG to standardize the interaction between 
application and network, initially for P2P application and now it is a good 
chance to continue optimization to support these new interactive services like 
Cloud Gaming, XR/AR, V2X application etc.
[Qin]: I agree to support further evolving of ALTO protocol.
To support new application and introduce further optimization for ALTO 
protocol, we need to get more implementation deployment and experience to help 
us better understand which piece works, which pieces not needed, which pieces 
need to be redesigned. ALTO protocol is initial designed for P2P, later on CDN 
application, it is generic protocol, Do we have P2P specific features that need 
to peel off? To get this question answer, we propose the first work item and 
the second item and will create wiki page to keep track of related 
concern/issues/report

Secondly, we have been working together with colleagues from network operator, 
network vendor and academy et. al. for quite long to perform ALTO-oriented 
research and also real network testing which have already show very clear 
benefits and we contribute MoWIE to this WG 
（https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/).
  We think the listed items, i.e. the generic protocol extension for policy 
attributer, proposed as the high priority for recharter proposal in IETF#110 
ALTO shows rough consensus to some extent. If ALTO WG doesn't continue these 
topics explicitly, it is very regretful and we really feel disappointed about 
this.

[Qin]: Please see the latest charter proposal, last work item we proposed based 
on list discussion
https://trac.ietf.org/trac/alto/wiki/v0.5-recharter
o Report back to the Area Director to identify any use cases that have strong 
support and a realistic chance of implementation and deployment.
New use cases documentation is encouraged, especially the use cases for new 
emerging applications as you mentioned, AR, VR, Cloud gaming, which have strong 
support.
For MOW

Re: [alto] WG Review: ALTO Charter Update(Internet mail)

[熊春山]

Hello WuQian and working group,

I provide our views on this recharter.

Firstly, we think ALTO is an IETF WG to standardize the interaction between 
application and network, initially for P2P application and now it is a good 
chance to continue optimization to support these new interactive services like 
Cloud Gaming, XR/AR, V2X application etc.

Secondly, we have been working together with colleagues from network operator, 
network vendor and academy et. al. for quite long to perform ALTO-oriented 
research and also real network testing which have already show very clear 
benefits and we contribute MoWIE to this WG 
（https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/).
  We think the listed items, i.e. the generic protocol extension for policy 
attributer, proposed as the high priority for recharter proposal in IETF#110 
ALTO shows rough consensus to some extent. If ALTO WG doesn't continue these 
topics explicitly, it is very regretful and we really feel disappointed about 
this.

Thirdly, there have been more and more interests in these interactive services 
from many SDOs including 3GPP and IEEE etc. In year 2020, IEEE has setup up a 
new working group related to cloud gaming. In 3GPP since 2019 we have led 
Rel-17 5G_AIS (Advanced Interactive Services) and also we are driving another 
new Rel-18 study item in 3GPP to further enhance interaction between 
application and network for these interactive services from network 
perspective. If IETF can have corresponding standard activities (as 3GPP and 
IEEE are working on network and lower layers), that would be great for 
standards synergy and Internet ecosystem. Otherwise, it is really a pity that 
we missed a very important technical direction in Internet.

Therefore, we sincerely hope ALTO can re-consider such way forward.

BRs,
Chunshan Xiong

From: alto  On Behalf Of Qin Wu
Sent: Saturday, April 24, 2021 12:06 AM
To: IETF ALTO 
Cc: alto-cha...@ietf.org; Zaheduzzaman Sarker 
Subject: [alto] WG Review: ALTO Charter Update(Internet mail)


Dear Martin and working group,



Thank you for the useful rechartering discussions on the mailing list and at 
IETF-110.



I have listened to the people who say that further protocol work needs to be 
based on strong deployment needs, and I also hear very many different use cases 
proposed. I think we need more discussion and understanding to work out which 
use cases are high priority and which are more research-based.



This makes me think that we need a small short-term recharter to allow us to 
work on immediate issues (protocol maintenance, operational support) while we 
discuss and investigate the best uses cases for further work.



So I propose this as our new charter with input from our AD.

=

Application-Layer Traffic Optimization Working Group Charter Update

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 proof-of-concepts of ALTO based solutions supporting applications such 
as content distribution networks (CDN).

To support current and future deployments of ALTO, the working group is now 
chartered for the following activities:

o Provide a place to collect implementation deployment and experience. It is 
hoped that implementer and deployers of ALTO will report their experiences on 
the mailing list, and the working group will track implementation and 
deployment reports on a wiki or in an Internet-Draft.

o Perform protocol maintenance for the existing published protocol. It is 
anticipated that questions and issues will arise concerning the existing 
protocol specifications: The working group will develop and publish updates as 
necessary to resolve any interoperability, performance, operational, or 
security, or privacy problems that arise. The working group will also help 
resolve any errata reports that are raised. This work item might be addressed 
by discussions and reviews, or might require additional RFCs.

o Develop operational support tools for the ALTO protocol. Based on experience 
from deployments, the advice in RFC 7971, 
and considering the latest opinions and techniques from the Operations and 
Management Area, the working group will develop tools to configure, operate, 
and manage the ALTO protocol and networks that use ALTO. This may include YANG 
models and OAM mechanisms. The working group may also update RFC 
7971 in the light of new experience and 
protocol features that were added to ALTO after that RFC was published.

o Support for modern transport protocols. When work on ALTO began, the protocol 
was supported using HTTP version 1. Since then, the IETF has

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 informat

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.

Re: [alto] ALTO Draft ReCharter WG review(Internet mail)

[熊春山]

Hello Qin,

Normally, the 1080p/720p indicates the bitrates.

The cloud gaming server only provides the bitrate span to the ALTO server( to 
the 5G network), it does not need to provide the encoding scheme information to 
the 5G network.

Normally we/Tencent use H.264 encoding scheme because there are a lot of open 
source available,  but some vide streaming service are testing to use VP8 
encoding scheme to compare the performance between different encoding scheme. 
But H.264 is used in most video streaming.

BRs,
Chunshan Xiong

From: alto  On Behalf Of Qin Wu
Sent: Monday, March 8, 2021 3:03 PM
To: Li Gang ; kai...@scu.edu.cn
Cc: alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 
Subject: Re: [alto] ALTO Draft ReCharter WG review(Internet mail)

Thanks for your clarification, I think 1080p and 720p are resolution, 
corresponding to HD, SD video, or 4.5Mbit/s, 2.5 Mbit/s bit rate if you are 
using H.264 encoding scheme.
Have you considered to use VP8 encoding scheme?

-Qin
发件人: Li Gang [mailto:ligan...@chinamobile.com]
发送时间: 2021年3月8日 11:42
收件人: Qin Wu mailto:bill...@huawei.com>>; 
kai...@scu.edu.cn
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org; 'IETF ALTO' 
mailto:alto@ietf.org>>
主题: RE: [alto] ALTO Draft ReCharter WG review

Hi, Qin,
Please see my reply inline.

Li Gang

From: Qin Wu [mailto:bill...@huawei.com]
Sent: Monday, March 8, 2021 10:52 AM
To: Li Gang; kai...@scu.edu.cn
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org; 'IETF ALTO'
Subject: RE: [alto] ALTO Draft ReCharter WG review

Hi, Gang:
Thanks for sharing your use case, let me rephrase what you envision for your 
use case,
You want to express QoS requirement in the subscription request, the network 
exposes the network information via notification in response to subscription 
request,
application operators can tune adaptive rate to improve user QoE based on the 
network information change.

[Gang]: yes

Can you clarify a little bit about specific application traffic patterns?

[Gang]: let me take video streaming as an example, normally the downlink 
streaming content would be segmented into pieces for `10 seconds. For each 
piece, multiple video encoding rates, for example 1080p, 720p …, can be 
provided and adjusted by server. For each encoding rate, the QoS requirement 
(e.g. throughput, latency) is different. The network can provide such 
information change  (e.g. whether QoS requirement for 1080p, 720p is fulfilled 
or not) via pub/sub, which help application operator tune encoding rate.

Secondly, I agree fine granularity pub sub can consider one time subscription 
and configure wait time as subscription policy to alleviate the signaling load 
on the network.

-Qin
发件人: Li Gang [mailto:ligan...@chinamobile.com]
发送时间: 2021年3月7日 16:30
收件人: kai...@scu.edu.cn; Qin Wu 
mailto:bill...@huawei.com>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org; 'IETF ALTO' 
mailto:alto@ietf.org>>
主题: RE: [alto] ALTO Draft ReCharter WG review

Hi, Kai and Qin,

Thanks for triggering the discussion on  the 2nd item of the recharter text.
I agree that it would be better to define a generic pub/sub framework 
irrespective of specific transport protocol.
We can start with a simple pub/sub mechanism, which is driven by concrete use 
cases and then consider to extend as needed.

Some of my thoughts are inline.

Li Gang

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of 
kai...@scu.edu.cn
Sent: Friday, March 5, 2021 11:03 AM
To: Qin Wu
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org; IETF ALTO
Subject: Re: [alto] ALTO Draft ReCharter WG review


Hi Qin,



Thanks for the comments. A quick summary of my response is



1. "Pub/sub" means different things in different contexts and I think we must 
clarify what it means in the context of distributing ALTO information.

2. There are two ways of realizing complex "pub/sub" of ALTO information but I 
think they are fundamentally different deployment settings for one generic 
framework (whose details are, unfortunately, not thought through yet).



Please see the details inline.



Best,

Kai

-Original Messages-
From:"Qin Wu" mailto:bill...@huawei.com>>
Sent Time:2021-03-04 22:21:06 (Thursday)
To: "kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>
Cc: "alto-cha...@ietf.org" 
mailto:alto-cha...@ietf.org>>, 
"alto-...@ietf.org" 
mailto:alto-...@ietf.org>>, "IETF ALTO" 
mailto:alto@ietf.org>>
Subject: Re: [alto] ALTO Draft ReCharter WG review
Kai:
发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2021年3月3日 21:40
收件人: Qin Wu mailto:bill...@huawei.com>>
抄送: IETF ALTO mailto:alto@ietf.org>>; 
alt

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

[熊春山]

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.





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



BRs,
Chunshan Xiong

From: alto  On Behalf Of Y. Richard Yang
Sent: Wednesday, March 10, 2021 12:13 PM
To: Li Gang 
Cc: alto-cha...@ietf.org; alto-...@ietf.org; Kai Gao ; Qin 
Wu ; IETF ALTO 
Subject: [alto] Pub/sub thread; Was Re: ALTO Draft ReCharter WG review(Internet 
mail)

Dear all,

I renamed the generic email Subject line so that we may focus this thread on 
item 2.

Here are two quick comments related with this thread, and I will go to more 
details as soon as I can.

1. ALTO SSE appears to be a quite useful service and it helps to adapt it to 
use more modern transport such as HTTP/2, quic.

We may consider this under the sub/pub umbrella by considering the service as a 
special sub/pub:
ALTO client can manage its subscription of network info to be pushed to it, 
where the granularity of subscription is individual ALTO resource query; in 
this model, the granularity can be quite fine-grained, depending on the query 
granularity. Hence, if we want fine-grained subscriptions, we can introduce 
these queries and leave the push/incremental encoding mechanism/framework alone.

2. Can we clarify more on the sub/pub use cases? A typical use case of a 
sub/pub system C is to facilitate the communication of other entities such as A 
and B. Hence, if the ALTO server is C, then who are the A and B? I can think of 
use cases where clients, for example, in a mobility/weakly connected setting, 
are A and B. Or the use case is about developing C, and the A and B are ALTO 
client/server. It helps to clarify.

Richard

On Sun, Mar 7, 2021 at 10:42 PM Li Gang 
mailto:ligan...@chinamo

[alto] Welcome your comments on the new draft-huang-alto-mowie-for-network-aware-app-02

[熊春山]

Hello all,

A updated  alto draft 
https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/ 
for draft-huang-alto-mowie-for-network-aware-app-02 is submitted.

There are some minor texts and format corrections.
Welcome your comments.
BRs,
Chunshan Xiong
Tencent

___
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(Internet mail)

[熊春山]

Hello Qin,

Please check my inline clarification for your questions.
Since there is an online 3GPP standard meeting in the last week, my response is 
some late.

BRs,
Chunshan Xiong

From: Qin Wu 
Sent: Monday, November 16, 2020 9:21 PM
To: chunshxiong(熊春山) ; alto 
Subject: RE: [alto] ALTO recharter: proposed item - Extends the ALTO Service to 
provide cellular network Information(Internet mail)

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 mailto:alto@ietf.org>>
主题: [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?
[Chunshan] One of key characteristics of cellular network information is the 
freshness. Unlike the traditional ALTO network information which is much more 
static for a long time, the cellular network information is changed very 
quickly , e.g. for millisecond level to second level.  In such case, maybe the 
traditional ALTO network information is not suitable for the cellular network 
information.

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.
[Chunshan] Yes, all these contributions are good start point for the cellular 
network information, and all these works needs to be consider as a whole output.


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?
[Chunshan] Yes, the NEF is the egress port to exposure the cellular network 
information.
But the current specification only defines the capability on how to provide the 
cellular network information to the outside world, but it does not define which 
cellular network information to be provided.


+++ 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?
[Chunshan] Just said in the previous part, One of key characteristics of 
cellular network information is the freshness. Unlike the traditional ALTO 
network information which is much more static for a long time, the cellular 
network information is changed very quickly ,we can reuse some cost map, but we 
need to add freshness information to limit the time of usability.
Normally, the 5G network does not explicitly provide such endpoint information, 
bu

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


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.

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

+++ Solution for Issue 4:
   - Radio channel status: e.g. SINR, RSRP/RSRQ, CQI, MCS
   - L2 user plane measurements: e.g. thoughtputthroughput, latency
   - 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.

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.

+++ 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 business model. On one hand, operators can increase 
revenue by charging from OTT vendors. On the other hand, it is helpful to 
improve user QoE and increase user loyalty.

+++ Is the info from a single device or a set of devices, where the devices 
involved can span multiple autonomous domains, multiple wireless links may get 
involved? What does mean for this context?
   - For local breakout scenario, the NEF and radio network are within the 
same operator, no problem to get information.
   - For home domain routed scenario, the NEF and radio network belongs to 
different operators, but since the home routed traffic, there is a roaming 
agreement for multiple domains and NEF can provide some celluar network 
information.


4.Who will work on it?
   - China Mobile, Tencent and Welcome more.

5. Rough Planning and outputs
   - Mar 2021   Problem Description on support cellular network
   - Nov 2021   Extend ALTO Information Service with Cellular 
network information and its information freshness
   - 2022  Best Practice to provide deployment guideline 
for network information exposure


From: yanniszhang(张云飞) 
Sent: Saturday, October 31, 2020 1:49 PM
To: ligangyf ; chunshxiong(熊春山) 
; yry ; alto 
Subject: Re: RE: [alto] ALTO recharter to support cellular network use 
cases(Internet mail)

Hi Ligang,
   Please see inline for the reply.

BR
Yunfei


yanniszhang(张云飞)

From: Li Gang<mailto:ligan...@chinamobile.com>
Date: 2020-10-30 16:58
To: yanniszhang(张云飞)<mailto:yanniszh...@tencent.com>; 
chunshxiong(熊春山)<mailto:chunshxi...@tencent.com>; 
'yry'<mailto:y...@cs.yale.edu>; 'alto'<mailto:alto@ietf.org>
Subject: RE: Re: [alto] ALTO recharter to support cellular network use 
cases(Internet mail)
Hi, Yunfei, please see inline for some of my reply.

From: yanniszhang(张云飞) [mailto:yanniszh...@tencent.com]
Sent: Thursday, October 29, 2020 9:50 PM
To: ligangyf; chunshxiong(熊春山); yry; alto
Subject: Re: Re: [alto] ALTO recharter to support cel

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

[alto] ALTO recharter to support cellular network use cases

[熊春山]

Hello All,

Now 3G/4G/5G becomes the infrastructure of a country. Business, education and 
entertainment are using the cellular network to provide seamless access.

To help the applications  (e.g. in the cloud) to provide good QoE to the end 
user, the application in the cloud needs to get the cellular network 
information, e.g. the available bitrate , the current latency in the cellular 
network, to adaptively change its bitrate or the video resolution.

Here, based on the above assumption, I identify the following new directions 
for ALTO re-charter:


1)  propose to include cellular network information to be provided to the 
ALTO Server,  then the ALTO server can further to provide the cellular network  
information to the ALTO client.



2)  Define the cellular Network information with validity time .
Because the dynamic characteristics of the radio link, the information provided 
by the cellular network is almost always fresh and changing. So it is proposed 
that the freshness of the cellular network information provided is associated 
with a  validity time,  before the validity time expires, the cellular network 
information is fresh and can be trusted used, after validity time expires, the 
cellular network information is outdated  and cannot be trusted used.

One question is which network function sets the validity time for the cellular 
network information ? In my understanding, it is the 3G/4G/5G network nodes who 
provides such cellular network information will set the validity time.


3)  Define how the cellular network information is provided to the ALTO 
server

In  4G , SCEF-based  network information exposure architecture is defined.

In 5G, NEF-based network information exposure architecture is defined.

These SCEF and NEF based  network information exposure architecture can provide 
some information to the 3rd party via the Restful based API. The information 
provided by these two interface are normally events (e.g. UE’s connect 
available, or UE enters a defined area) which happens at current time. These 
real time events are very helpful some applications but it is still very 
limited for a lot of cloud-based applications.

Also 3GPP has defined CAPIF to help application to discovery and use the API 
provided by the 3GPP 3/4/5G.



So it is proposed that the ALTO Server  still  uses the open NEF-based 
interface to get cellular network information.

4)  Define how the ALTO Server get the fresh cellular network information

The NEF provided real-time events are valid on from the time of the  exposure 
to 3rd party because the event normally is a status, if the status is changed, 
a new event is provided. In such case, the event is valid always.



But the bitrate of radio link and the current latency in the 5G system are 
provided with detailed a value and not a status, in such case, a validity time 
is needed to define how long such value is usable as defined in 1).



In the 5G, the NET gets the network information from other network functions 
via the control plane. But these fresh cellular network information are changed 
frequently, this will introduce too much control plane signaling in the 5G. A 
reliable and efficient way for the NEF to get such fresh network information is 
needed in the 5G system.

3GPP 5G release-17 has defined a SID on EC enhancement to support cellular 
network information to the EC application server with low-latency. Now, 3GPP 
has agreed  (but still does not make final decision) that the  network 
information collection and exposure via combined IB and OB mechanism ( e.g. IB 
information signaling from radio network to the UPF via the user plane GTP-U 
header (this technology has been defined in release 16) and the UPF forwards 
such network information to the local NEF via a new control plane interface ( 
assumed to be defined in 3GPP release-17 Edge computing to support  low latency 
information exposure). It is assumed that there is an interface between local 
NEF and central NEF, in such case, the local NEF also can request (non latency 
sensitive) network information from the central NEF.

Based on such Release-17 EC low-latency information exposure technologies, the 
NEF can get fresh cellular network information from the user plane and from the 
radio station and provides these fresh cellular network information to the ALTO 
Server.




5)  Define which fresh cellular network information to be defined in the 
ALTO Server
This is very important question for us, at the start point, I think the bit 
rate and communication latency are needed, new  information can be defined.
And we also need to identify whether such cellular network information can be 
provided by the 5G network, If we need these network information, we can send 
LS to 3GPP to ask for exposure such information.

The above 5 bullets are the summary of my thinking on how to provide fresh 
cellular network information to the ALTO Server.

Thanks very much to  a lot peo

Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG(Internet mail)

[熊春山]

Hello all,

The discussions are so interesting.

I provide my view on ALTO as below.

Normally, for the routing procedure, there are two types of routing 
protocols/procedures, one is interior-domain routing and another is 
inter-domain routing.
For the interior-domain routing, the routers in the path selects the next 
router based on the internal calculated lowest "cost".
For the inter-domain routing, the routers in the path selects the next router 
based on the local domain configured "policies" or "rules".

The current ALTO server provides the similar function of the "router" in the 
interior domain: router is select next destination "router" based on the lowest 
cost, while the ALTO server provides the best destination "resource provider" 
based on lowest cost.

So for the ALTO to support inter-domain, the similar routing technologies can 
be used, e.g. the BGP-like technologies can be reused. i.e. the ALTO servers 
from different domains need to talk each to exchange the " resource provider 
and related cost" information, but the " resource provider and related cost" 
information are provided in the ALTO server as BGP as policies and rules 
configured by the domain manager.

For the ALTO client, it must not access directly to the inter-domain ALTO 
server, it can access its interior-domain ALTO server, this interior-domain 
ALTO server will talk with its domain border ALTO server and provides the final 
destination to the ALTO client.

So there are type communications :1) interior ALTO server to domain border ALTO 
server; 2) inter domain ALTO server

Here is my basic understanding on the inter-domain ALTO, it is just my personal 
view.


I find that SDN-based WAN is proposed in some paper, the SDN controller selects 
a routing path based on the global view on the WAN. Maybe the SDN-based WAN 
technologies can be investigated to identify whether the SDN controller helps 
to select a best destination based on the global view of the WAN. In such case, 
the interior ALTO server needs to communicate with the SDN controller. The 
communication between two SDN controller is outside of ALTO. With this method, 
it will simplify the standard work in ALTO, but we need to cooperate with 
SD-WAN work (it is still unclear in which organization).  It is just a draft 
idea, I need more time to study this possibility, but I hope people also to 
notice this direction.


BRs,
Chunshan Xiong

-Original Message-
From: alto  On Behalf Of Jensen Zhang
Sent: Saturday, July 18, 2020 7:08 AM
To: Sebastian Kiesel 
Cc: Ingmar Poese ; IETF ALTO 
Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and 
discussion on re-chartering the WG(Internet mail)

Hi Sebastian, Ingmar, Danny, all,

First, thanks for all your discussions. I also have several comments.
Please see inline.

On Tue, Jul 14, 2020 at 2:39 PM Sebastian Kiesel  wrote:
>
> Hi Ingmar, all,
>
> On Tue, Jul 14, 2020 at 01:33:37PM +0200, Ingmar Poese wrote:
> > Am 14.07.20 um 11:56 schrieb Sebastian Kiesel:
> > > On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote:
> > > > > Even the very first ALTO use case was multi-domain in some sense:
> > > > > the bittorrent clients in the access networks of Comcast and 
> > > > > Sprint, the pirate bay tracker in Sweden, that could be seen as three 
> > > > > domains.
> > > > > The examples in the drafts you have listed are obviously 
> > > > > different and more complex, but I am still struggling to tell 
> > > > > what exactly is new and needs to be done.
> > > >
> > > > Yes, I remember your question. I will try to clarify our 
> > > > multi-domain approach.
> > > >  From your P2P example, we have the next figure:
> > > > [image: multi-domain-ALTO.jpg]
> > > > An ALTO server in each domain will provide only local 
> > > > information to ALTO clients. In the example, the tracker (ALTO 
> > > > client) receives topology-/policy-related information of a 
> > > > single domain (AS1 or AS2). Let's call it "single-domain information 
> > > > exposure".
> > >
> > > While your observation is probably true in most deployments we 
> > > have seen so far, I do not completely agree on an architectural level.
> > >
> > > We have designed the ALTO protocol such that an ALTO client may 
> > > ask one ALTO server *any* question, e.g., "give me network map and 
> > > cost map for the whole Internet address space" or ECS(IP1, IP2) 
> > > where IP1 and IP2 are arbitrary IP addresses in whatever domain.
> > > The idea that there might be more than one ALTO server, and that 
> > > one ALTO server might give better answers to some specific 
> > > questions while another ALTO server might give better answers to 
> > > other questions, was in our mind when we worked on the protocol, 
> > > but it did not result in any specific feature of the base protocol 
> > > that would deal with that situation.
> >
> > I would actually like to go a little further on this point. At the 
> > early stages, if i remember co

Re: [alto] Welcome your comments on new draft-huang-alto-mowie-for-network-aware-app(Internet mail)

[熊春山]

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

Sent: Thursday, May 14, 2020 1:20 AM
To: chunshxiong(熊春山) ; alto@ietf.org
Cc: Y. Richard Yang 
Subject: RE: Re: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunchan,

Thanks a lot for your responses. Please see additional comments inline.
Hoping the message gets through the ALTO mailing list as well,
Best regards,
Sabine


From: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Sent: Thursday, May 7, 2020 11:27 AM
To: alto@ietf.org<mailto:alto@ietf.org>
Cc: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 Y. Richard Yang mailto:y...@cs.yale.edu>>
Subject: RE: Re: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Sabine,

Please see my response inline.

It seems that there is something wrong from the alto wg mailing list. I include 
you and Richard in CC and hope you can receive the email directly. And  I will 
write an email to the alto chairmans.

BRs,
Chunshan Xiong

From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Tuesday, May 5, 2020 2:45 AM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Cc: 'Richard Yang' mailto:y...@cs.yale.edu>>
Subject: FW: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunshan,

Please see my response in the e-mail below. I initially have put the ALTO WG 
mailing list in Cc but my e-mail has been rejected.
We may want to let the WG chairs know about this. In the meantime, we can 
continue our discussion off-line and bring it back to the ALTO mailing list 
when the issue is solved.

Best regards,
Sabine


From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Monday, May 4, 2020 8:41 PM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>; 
；alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello Chunshan,

Thanks for your responses,
Please see inline,
Best regards,
Sabine


From: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Sent: Monday, April 27, 2020 1:26 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 ；alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello Sebine,

Thanks a lot for your comments.

Please check my responses inline...

BRs,
Chunshan Xiong

From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Tuesday, April 21, 2020 11:19 AM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>; 
alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunshan Xiong,

Thanks a lot for bringing these 5G use cases to the ALTO WG, and for the 
comprehensive description of related experiments. Indeed apps such as Low Delay 
Live Show are getting highly important in the current context of confinement, 
where classes are all getting virtual and interactive. The challenges faced by 
networks are an additional motivation to further optimize traffic  for such 
applications.

I would like to initiate discussions on section 5  "Standardization 
Considerations of MoWIE as an Extension to ALTO", where  some key 
considerations are provided.

1 - Regarding item "Network information selection and binding consideration": 
indeed, a flexible mechanism deciding which metrics an ALTO client should query 
will allow to support a variety of applications and contexts,  that may each 
require a particular set of metrics.  Such a mechanism, that prepares input to 
ALTO Client requests,  will use the IRD information, starting with the list of 
available cost metrics.
- Did you identify particular IRD features that need to be added or upgraded to 
support flexibility for ALTO Client requests?
[Chunshan Xiong] currently, based on my understanding, the validity time (or 
freshness time) of the network information is needed.
[ [SR] ]  The ALTO Performance Cost Metrics extension that is being specified 
indeed, does not mandate to provide such information. There is a discussion on 
information “freshness”, for metrics that impact the QoE and whose values 
change at a significant frequency and in an unpredictable way. For future 
extensions, it may be interesting to start a discussion on the pros, the cons, 
the how to convey such a freshness property in a reliable and light way.
[Chunshan Xiong] Thanks to provide these background information, I think the 
validity time information is an important parameter and needs to be considered, 
also I agree with you that more discussion a

Re: [alto] Welcome your comments on new draft-huang-alto-mowie-for-network-aware-app(Internet mail)

[熊春山]

Hello Sabine,

Please see my response inline.

It seems that there is something wrong from the alto wg mailing list. I include 
you and Richard in CC and hope you can receive the email directly. And  I will 
write an email to the alto chairmans.

BRs,
Chunshan Xiong

From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Tuesday, May 5, 2020 2:45 AM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Cc: 'Richard Yang' mailto:y...@cs.yale.edu>>
Subject: FW: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunshan,

Please see my response in the e-mail below. I initially have put the ALTO WG 
mailing list in Cc but my e-mail has been rejected.
We may want to let the WG chairs know about this. In the meantime, we can 
continue our discussion off-line and bring it back to the ALTO mailing list 
when the issue is solved.

Best regards,
Sabine


From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Monday, May 4, 2020 8:41 PM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>; 
；alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello Chunshan,

Thanks for your responses,
Please see inline,
Best regards,
Sabine


From: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Sent: Monday, April 27, 2020 1:26 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 ；alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello Sebine,

Thanks a lot for your comments.

Please check my responses inline...

BRs,
Chunshan Xiong

From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Tuesday, April 21, 2020 11:19 AM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>; 
alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunshan Xiong,

Thanks a lot for bringing these 5G use cases to the ALTO WG, and for the 
comprehensive description of related experiments. Indeed apps such as Low Delay 
Live Show are getting highly important in the current context of confinement, 
where classes are all getting virtual and interactive. The challenges faced by 
networks are an additional motivation to further optimize traffic  for such 
applications.

I would like to initiate discussions on section 5  "Standardization 
Considerations of MoWIE as an Extension to ALTO", where  some key 
considerations are provided.

1 - Regarding item "Network information selection and binding consideration": 
indeed, a flexible mechanism deciding which metrics an ALTO client should query 
will allow to support a variety of applications and contexts,  that may each 
require a particular set of metrics.  Such a mechanism, that prepares input to 
ALTO Client requests,  will use the IRD information, starting with the list of 
available cost metrics.
- Did you identify particular IRD features that need to be added or upgraded to 
support flexibility for ALTO Client requests?
[Chunshan Xiong] currently, based on my understanding, the validity time (or 
freshness time) of the network information is needed.
[ [SR] ]  The ALTO Performance Cost Metrics extension that is being specified 
indeed, does not mandate to provide such information. There is a discussion on 
information “freshness”, for metrics that impact the QoE and whose values 
change at a significant frequency and in an unpredictable way. For future 
extensions, it may be interesting to start a discussion on the pros, the cons, 
the how to convey such a freshness property in a reliable and light way.
[Chunshan Xiong] Thanks to provide these background information, I think the 
validity time information is an important parameter and needs to be considered, 
also I agree with you that more discussion are needed to reflect this new 
character.

- What type of flexibility is otherwise missing in ALTO information resources?
[Chunshan Xiong] Now the wireless network (e.g. through NWDAF and other 
devices) can collect wireless link and network information for radio station 
and other types of network elements, and also supports applications to access 
these information through a standard interface. Our Server application can 
query and get network information with standardized HTTP-based message, which 
is comparable with ALTO query and response. The standardized HTTP-based message 
even support the server push mechanism after the new information is available 
(i.e. the network information value is changed) which is also comparable with 
the Alto SSE mechanism.
 Alto resources based on the “static” network map are used to select a path or 
end point t

Re: [alto] ALTO Interim in lieu of IETF 107(Internet mail)

[熊春山]

Hello Vijay,

Thank, I prefer slot 0, 1, 7, 8.

BRs,
Chunshan Xiong
Tencent
From: alto  On Behalf Of Vijay Gurbani
Sent: Saturday, March 14, 2020 1:59 AM
To: IETF ALTO 
Subject: [alto] ALTO Interim in lieu of IETF 107(Internet mail)

All: The IESG has been working on coming up with a virtual interim schedule for 
WGs that would have met in Vancouver.  As the original schedule avoided WG and 
RG conflicts to the maximum extent possible, the virtual interim schedule has 
been created so that working groups and research groups can be reasonably sure 
that most participants will not have a conflict with another IETF interim 
meeting on the same day.

For ALTO, IESG has suggested Tue, Apr 21.  We will plan to hold a virtual 
interim on that day.  While we can decide another day besides the IESG 
suggested one, I would hesitate to do so for a variety of reasons, the most 
important of which is that we will have to ensure that our chosen day does not 
conflict with other WGs, BoFs, and RGs, that WG list members may be interested 
in.  Thus, it seems safe to stay with the IESG suggested date of Apr 21, as 
that date has honored all of the WG/RG conflicts with ALTO.

What we need to do soon (48 hours or so) is to agree on a specific time for Apr 
21 so Jan and I can set the wheels in motion to schedule the virtual interim on 
Apr 21.

Here are the options, please reply with your preferred option on the list.  Jan 
and I will collect all of the responses we receive by Sunday night, and choose 
the one that is most frequent by Mon AM.  I know Europe has not yet changed 
their clocks, so I will leave the times below in US Central time zone (which is 
now on daylight savings time).  So please adjust accordingly for your locale.  
All times are for Apr 21, 2020.

0. 5:00am - 7:00am US Central
1. 7:00am - 9:00am US Central
2. 9:00am - 11:00am US Central
3. 11:00am - 1:00pm US Central
4. 1:00pm - 3:00pm US Central
5. 3:00pm - 5:00pm US Central
6. 5:00pm - 7:00 pm US central *
7. 7:00pm - 9:00pm US central *
8. 9:00pm - 11:00pm US Central  *

* I will not be able to make these timeslots as they overlap with the class I 
teach.

Thank you,

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

[alto] Welcome your comments on new draft-huang-alto-mowie-for-network-aware-app

[熊春山]

Hello all,

A new alto draft 
https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/ 
is submitted.

In this paper, we uses the network information of Mobile and Wireless 
Information Exposure (MoWIE) to adapt key control knobs such as media codec 
scheme, encapsulation and application logical function to improve the QoE. We 
provide some detailed testing and evaluations. And we discuss how MoWIE can be 
a systematic extension of the ALTO protocol, to expose more lower-layer and 
finer grain network dynamics.
We spend a lot of time and testing to produce this paper, welcome your comments 
and we will update the testing and improve the paper based on your comments.

BRs,
Chunshan Xiong
Tencent

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