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

["chunshxiong(熊春山)" <[e-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) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 5, 2020 2:45 AM
To: chunshxiong(熊春山) <[e-mail]<mailto:[e-mail]>>
Cc: 'Richard Yang' <[e-mail]<mailto:[e-mail]>>
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(熊春山) <[e-mail]<mailto:[e-mail]>>; ；[e-mail]<mailto:[e-mail]>
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(熊春山) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, April 27, 2020 1:26 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]<mailto:[e-mail]>>; ；[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, April 21, 2020 11:19 AM
To: chunshxiong(熊春山) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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.
[ [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 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.
[ [SR] ]  Does this mean the application would like the possibility to switch to another path or at least to have some details on specific parts  in the path to see whether this path is OK?
[Chunshan Xiong] In this paper , we only consider how to leverage the network information to further improve the application QoE along a path, but we don’t preclude support to switching to another path, but however, we would like to start from single path at the beginning and path switching is not the target of this paper.

Maybe it is not the “flexibility” problem, but I think how to get the real-time path(or network) characteristics is needed.
[ [SR] ]  What frequency would “real-time” correspond? This relates to point 2 below on how frequently network information updates are needed.
[Chunshan Xiong] Yes, the frequency of real-time information needs to consider some different dimensions:1) the characteristics of the information; 2)the load introduced. 3) how the application uses this information to improve the QoE.

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.
[ [SR] ] This is quite good news. Providing information updates to applications every 30 seconds seems achievable and even a higher frequency should be doable. Of course, it depends on how many Clients are querying ALTO Server information, and how frequent queries in cellular networks can be moderated by a smaller area and thus number of querying applications.
[Chunshan Xiong] To support ABR-based MPEG-DASH, per  5s  of network bitrate information query/updates may be needed.  For high interactive application like cloud gaming, a further shorter time of information query/updates will be helpful, but will introduce load to the 5G network and the application server.

Some network information which is not changed so often can be also HTTP pushed to the server without frequent query.
[ [SR] ] Indeed, and that further motivates the provision of a hint on how frequently the exposed information is changing
[Chunshan Xiong] yes.

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.
[ [SR] ] Does it mean that application level information is fast when no network information is processed?
[Chunshan Xiong] When no processing of network information, it need to execute application level "blind"measurement fastly.  But with the help of  network inforamation, frequent application layer measurment can be reduced.


If we have MoWIE information in time, application layer moniortoring is therefore reduced.
[ [SR] ] Does it mean that application layer monitoring is reduced when network information is provided and replaces application layer information?
[Chunshan Xiong] Application Layer information is still needed e.g. it can provide some application specific information to improve the QoE, e.g. information on the buffer in the client APP. However the number of application layer measurement can be 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]<mailto:[e-mail]>> On Behalf Of chunshxiong(???)
Sent: Tuesday, March 10, 2020 2:35 AM
To: [e-mail]<mailto:[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