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 <chunshxi...@tencent.com> 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 <y...@cs.yale.edu> 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:* 'alto@ietf.org' <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) < sabine.randriam...@nokia-bell-labs.com> *Sent:* Tuesday, April 21, 2020 11:19 AM *To:* chunshxiong(熊春山) <chunshxi...@tencent.com>; 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.* - 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 <alto-boun...@ietf.org> *On Behalf Of *chunshxiong(???) *Sent:* Tuesday, March 10, 2020 2:35 AM *To:* alto@ietf.org *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
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto