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

["Y. Richard Yang" <[e-mail]>]

Sabine, all,

Forward email from Chunshan whose reply to Sabine’s comments cannot be
posted to this list. It looks that sometime we do have mailing list access
problems.

Richard

---------- Forwarded message ---------
From: chunshxiong <[e-mail]>
Date: Tue, Apr 28, 2020 at 10:00 PM
Subject: FW: [alto] Welcome your comments on new
draft-huang-alto-mowie-for-network-aware-app
To: Y. Richard Yang <[e-mail]>

Hello Richard,

Can you help me to send this email to Alto working group ?

I send this email many times successfully from Outlook, but this email does
not show up in the alto work group.

I have asked Tencent IT to investigate the problem, but it seems that they
need time and the 1st May holidays are coming and this email will be
delayed too long.

BRs,

Chunshan Xiong

*From:* chunshxiong(熊春山)
*Sent:* Monday, April 27, 2020 7:26 PM
*To:* '[e-mail]' <[e-mail]>
*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) <
[e-mail]>
*Sent:* Tuesday, April 21, 2020 11:19 AM
*To:* chunshxiong(熊春山) <[e-mail]>; [e-mail]
*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.*



- 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 to communicate from a set of paths or end points , the
selected resource can be used to save the network resource and improve the
APP QoE. But the path characteristics (i.e. the network characteristics)
are often changed  in the mobile and wireless network. So select a “right”
path(or end point) is not enough. For the 5G cloud based services with
mobile edge servers provisioning, the path may be very simple as "end
user->gNB->PSA->mobile edge server”, it may not possible to "switch"** to
another path. Rather how to adapt the policy based these path inforamation
is more important.*

*Maybe it is not the “flexibility” problem, but I think how to get the
real-time path(or network) characteristics is needed.*



2 - In item "Compact network information encoding consideration": the
processing overhead due to frequent updates especially for cellular
networks raises a key point regarding future ALTO extensions. Definitely,
ALTO is currently not meant to provide information at such a frequency.



- A first aspect to investigate in the ALTO WG may be requirements for
reliable cellular network information. In particular: at which frequency
does an application need to update network information?  In which extent
can cellular network information be aggregated over time and still be
reliable for an application? All this considering several applications and
several metrics.

*[Chunshan Xiong]  We support different kind of network information
acquisition based on either the 3GPP standardized interface and messages
e.g. via NEF/ NWDAF or vendor's solutions. In our initial test, the
applications gets the network information in per 1s. It doesn't necessarily
mean that the frequency MUST be at this grain. This frequecy is  just to
test how much pressure the wireless access and network can bear with
information exposure to applications. In many practical deployment network,
we notice that in many cases information such as MCS often remains
relatively stable at the level of 30 seconds and even sevel minutes.
Therefore, we do not have to make particularly frequent requests. *

*Some network information which is not changed so often can be also HTTP
pushed to the server without frequent query. *

*The current pure application level measurement and adaption is really
fast. The main reason is that the application is not clear about the
network change model and how frequently the network changes. If we have
MoWIE information in time, application layer moniortoring is therefore
reduced.*





- Another consideration on this item: very frequent network information
updates, if predicable may be conveyed in Calendars with SSE updates for
unexpected changes, but this is still near real time.  One way around is to
investigate extensions that may combine ALTO information with "conditional"
real-time information, obtained with other means. A first attempt in this
direction is proposed in “ALTO Contextual Cost Values” [1]  where ALTO
Calendar values are further interpreted with real-time parameter values
acquired by other means. This is preliminary work and does not directly
provide real-time cellular values but we may look at what can be extended
in the design, to support cases for very frequent network information
updates.

*[Chunshan Xiong]  It is a good idea, I need to improve this direction
research, and get help from you and Alto team. Our work is just a start
point, and need help to improve the work and the paper.*



I look forward to hearing your presentation at the interim meeting.

Best regards,

Sabine



[1] https://tools.ietf.org/id/draft-randriamasy-alto-cost-context-03.txt





*From:* alto <[e-mail]> *On Behalf Of *chunshxiong(???)
*Sent:* Tuesday, March 10, 2020 2:35 AM
*To:* [e-mail]
*Subject:* [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


-- 
Richard