[alto] 回复: [Internet]Re: ALTO meeting with PBE-CC team
Thanks for the notes. I agree with Qin's suggestions on moving forward the work. Yixue and Zhuoyun, would you please join the disucussion loop and give some input related to 3GPP? The synergy bw 3GPP and IETF, if possible, is very important when extending ALTO in cellular context. BR Yunfei yanniszhang(张云飞) 发件人： Jordi Ros Giralt<mailto:j...@qti.qualcomm.com> 发送时间： 2022-06-01 13:44 收件人： Y. Richard Yang<mailto:y...@cs.yale.edu>; ky...@cs.princeton.edu<mailto:ky...@cs.princeton.edu>; Jennifer Rexford<mailto:j...@cs.princeton.edu>; Yaxiong Xie<mailto:yaxio...@cs.princeton.edu>; Qin (Bill) Wu<mailto:bill...@huawei.com>; yanniszhang(张云飞)<mailto:yanniszh...@tencent.com>; alto@ietf.org<mailto:alto@ietf.org> 主题： [Internet]Re: ALTO meeting with PBE-CC team Hi all, Many thanks Mahdi for taking the meeting minutes yesterday. All, please find Mahdi's notes here and let us know if you'd like to add anything: https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2022.md Thank you all for participating in a very productive meeting. We look forward to continuing conversations on this important topic throughout the next weeks and as we go into the IETF 114 Meeting in July. Regards, Jordi on behalf of ALTO From: Y. Richard Yang Sent: Monday, May 30, 2022 16:27 To: ky...@cs.princeton.edu ; Jennifer Rexford ; Yaxiong Xie ; Qin (Bill) Wu ; Jordi Ros Giralt ; Yannis (Yunfei) Zhang Subject: Fwd: ALTO meeting with PBE-CC team WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Kyle, Jen, Yaxiong, We will use WebEx for the meeting tomorrow at 9 AM ET: JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=ma0e97cc97c4cd71bb59cf1a094682686 Meeting number (access code): 2424 884 8159 The goal of this initial meeting is to explore feasibility. We will give a quick overview of the current ALTO information structure. Then we can discuss how your work may be exposed to applications using standards to maximize its impact. If you want to go over your work and the latest updates before the discussion, please feel free to do so. We target a total of 45 mins. Below is a short email that we sent to the ALTO working group. Looking forward to seeing you tomorrow. Richard -- Forwarded message - From: Y. Richard Yang mailto:y...@cs.yale.edu>> Date: Mon, May 30, 2022 at 10:19 AM Subject: ALTO meeting with PBE-CC team To: IETF ALTO mailto:alto@ietf.org>> Hi ALTO group, We will meet with the PBE-CC team (Kyle Jamieson, Jen Rexford, and Yaxiong Xie, all from Princeton) tomorrow at 9:00 AM US ET to discuss the possibility of exposing more network information for applications. The direct relevant paper is: https://arxiv.org/abs/2002.03475 Another related work: https://dl.acm.org/doi/pdf/10.1145/3405672.3409489 One "grand" scheme is network information exposure from control channel, data channel, and control channel embedded in the data channel, e.g., https://datatracker.ietf.org/doc/rfc/ The meeting info is at the bottom of this page. Looking forward to see the design team and more tomorrow. - Richard on behalf of the meeting organizers JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=ma0e97cc97c4cd71bb59cf1a094682686 Meeting number (access code): 2424 884 8159 Meeting password: ymKtkapb394 TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY) +1-650-479-3208,<http://voice.google.com/calls?a=nc,%2B16504793208><http://voice.google.com/calls?a=nc,%2B16504793208>,24248848159## tel:%2B1-650-479-3208,,*01*24248848159%23%23*01* Call-in toll number (US/Canada) JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers https://ietf.webex.com/ietf/globalcallin.php?MTID=mb80643ae6bba4f3cf51f1b5918b3ce49 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:24248848...@ietf.webex.com<mailto:sip%3a24248848...@ietf.webex.com> You can also dial 173.243.2.68 and enter your meeting number. Can't join the meeting? https://collaborationhelp.cisco.com/article/WBX29055 IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
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 cellular network use cases(Internet mail) Hi Ligang, Please see inline for the reply. Thanks. BR Yunfei ________ yanniszhang(张云飞) From: Li Gang<mailto:ligan...@chinamobile.com> Date: 2020-10-29 18:02 To: chunshxiong(熊春山)<mailto:chunshxi...@tencent.com>; 'Y. Richard Yang'<mailto:y...@cs.yale.edu>; 'IETF ALTO'<mailto:alto@ietf.org> Subject: Re: [alto] ALTO recharter to support cellular network use cases(Internet mail) Dear ALTOers, Thank Chuanshan for your triggering discussion on cellular network information exposure via ALTO. Here are some of my thoughts. 1) It is beneficial to investigate cellular information exposure to improve especially cloud interactive applications. I think the following categories of cellular information can be considered, for example, radio channel status, L2 user plane measurements. In addition, different levels can also be considered, i.e. UE, slice, serving cell and neighboring cell. There are a number of specifications in 3GPP to define the specific meaning of each parameter and we don’t have to spend too much effort to define each of them. [Yunfei] Agree. We don't need to define them while we need to summarize these parameters (group) that matters for ALTO. 2) NEF, indeed, is a good interface for ALTO server to obtain cellular information. And for ALTO WG we don’t have to dive too much in how those information is conveyed within 3GPP network. In addition, the NEF deployment is quite flexible and can collocate with UPF and MEC, which enable low latency transmission. [Yunfei] Not very sure if current NEF can support very quick interaction bw network and application, even it's located in MEC. It doesn't work when the frequency of the parameters NEF exposes is quite low even if its transmission latency is low. Can you elabrate the degree BCP NEF can support? We may need to extend the requirement of NEF in 3GPP if necessary. [LiGang] I agree that we need to evaluate if the current flow can satisfy the performance requirement of frequent cellular info exposure. Actually there is no direct interface between UPF and NEF, and the flow has to go through RAN->UPF->SMF->NEF, which is quite lengthy. Some extension may be needed in 3GPP. Or even more drastically, in-band related solution might be considered. [Yunfei] Excatly I agree your comments on NEF in 3GPP. Best Regards, Li Gang China Mobile From: alto [mailto:alto-boun...@ietf.org] On Behalf Of chunshxiong(熊春山) Sent: Wednesday, October 28, 2020 5:43 PM To: Y. Richard Yang; IETF ALTO Subject: [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
Re: [alto] ALTO recharter to support cellular network use cases(Internet mail)
Hi Ligang, Please see inline for the reply. Thanks. BR Yunfei yanniszhang(张云飞) From: Li Gang<mailto:ligan...@chinamobile.com> Date: 2020-10-29 18:02 To: chunshxiong(熊春山)<mailto:chunshxi...@tencent.com>; 'Y. Richard Yang'<mailto:y...@cs.yale.edu>; 'IETF ALTO'<mailto:alto@ietf.org> Subject: Re: [alto] ALTO recharter to support cellular network use cases(Internet mail) Dear ALTOers, Thank Chuanshan for your triggering discussion on cellular network information exposure via ALTO. Here are some of my thoughts. 1) It is beneficial to investigate cellular information exposure to improve especially cloud interactive applications. I think the following categories of cellular information can be considered, for example, radio channel status, L2 user plane measurements. In addition, different levels can also be considered, i.e. UE, slice, serving cell and neighboring cell. There are a number of specifications in 3GPP to define the specific meaning of each parameter and we don’t have to spend too much effort to define each of them. [Yunfei] Agree. We don't need to define them while we need to summarize these parameters (group) that matters for ALTO. 2) NEF, indeed, is a good interface for ALTO server to obtain cellular information. And for ALTO WG we don’t have to dive too much in how those information is conveyed within 3GPP network. In addition, the NEF deployment is quite flexible and can collocate with UPF and MEC, which enable low latency transmission. [Yunfei] Not very sure if current NEF can support very quick interaction bw network and application, even it's located in MEC. It doesn't work when the frequency of the parameters NEF exposes is quite low even if its transmission latency is low. Can you elabrate the degree BCP NEF can support? We may need to extend the requirement of NEF in 3GPP if necessary. Best Regards, Li Gang China Mobile From: alto [mailto:alto-boun...@ietf.org] On Behalf Of chunshxiong(熊春山) Sent: Wednesday, October 28, 2020 5:43 PM To: Y. Richard Yang; IETF ALTO Subject: [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 provid
Re: [alto] Re-chartering guidance(Internet mail)
+1. Thanks Richard for the proposal. BR Yunfei yanniszhang(张云飞) From: Y. Richard Yang<mailto:y...@cs.yale.edu> Date: 2020-07-17 07:51 To: Vijay Gurbani<mailto:vijay.gurb...@gmail.com> CC: IETF ALTO<mailto:alto@ietf.org> Subject: Re: [alto] Re-chartering guidance(Internet mail) Hi Vijay, Jan, Martin, Thanks a lot! Personally, I like the decision. It can be more efficient and then lead to better results. As for the discussion leader, you can be a good, natural choice :-) Other potential candidates I see can include Sabine, Luis, Yunfei, and me, as these four people are already quite familiar with the existing documents, and also engaged in the many side meetings---there are multiple other younger candidates attending the many side meetings as well, but we may reduce their burden a bit. My proposal is that the chairs and the AD just approach one, and I have a strong belief that the others will just support---one very nice thing, which I like a lot about the alto WG, is that the members have strong collaborations and provide each other with very strong support. Hence, I see no problem with picking any of the five. These people come from different "segments": Sabine (Nokia, equipment), Luis (Telefonica, ISP), Yunfei (Tencent, app), Vijay (chair), and me (academia), and a single "leader" need the support of other segments anyway. Just my 2cents. Richard On Thu, Jul 16, 2020 at 6:26 PM Vijay Gurbani mailto:vijay.gurb...@gmail.com>> wrote: All: As you may have noticed from the ALTO agenda, the last hour of our meeting time is devoted to re-chartering discussion. At issue is how to best use that time? I laid out the two approaches on how to use this time in [1], and subsequent to that, Jan, Martin, and I have had a quick chat on providing some guidance to the principals so the hour can be used in the most optimal manner. To summarize [1], here are the two ways: One, have individual speakers talk about their specific pieces of work, and then have a recharter discussion that tries to weave in all of the presentations. Or two, have one presenter present a coherent rechartering discussion that includes works from others, and then lead the larger discussion. The former approach has been used in the past during BoFs, but may not be as applicable to us here for reasons enunciated in [2]. This leaves the second option: have a discussion leader who will summarize existing threads of work being sought in a recharter, and drive the discussion forward. We think this is the best way to move forward on rechartering discussion. Therefore, here is a concrete proposal: - Choose one person to lead the discussion. (Call him or her the discussion leader. I note that a subset of you have started a Google doc [3] that starts collecting potential recharter discussion items.) - The discussion leader leads the discussion, and everyone who wants to contribute a presentation that will have impact on the rechartering discussion should produce 1 slide (and 1 slide only, no title slide, just a single slide that includes architecture, results, and discussions on their specific work item for rechartering). The creators of this 1-slide send it to the discussion leader [4]. - The creator of the slide may come up to the mic and speak to their slide for 1 minute (and 1 minute only). This limit will be enforced by the chairs (apologies in advance). - The remaining time after a series of 1 minute presentations will be left for the broader discussion on rechartering. We hope that this provides some structure and guidance to the rechartering discussions. Please let Jan and me know if you have any questions, and please let us know who the discussion leader will be. [1] https://mailarchive.ietf.org/arch/msg/alto/rmBGzkM6hPPXLs1r5ngplxe-7ak/ [2] We eschew the BoF approach primarily driven by time constraints: consider that I counted at least 11 drats that were identified possible recharter discussion, and a separate request for a 20 minute slot. Assuming we allocate 5 minutes to each draft, we are looking at 55 minutes already! Not to mention the 20 minute slot. Therefore, allocating time for presentations will not be possible if we want to devote most of the time to discussing the recharter. [3] https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit [4] While I do not relish being the creator of these 1 minute slides, I have found them to be very effective at focusing on the main message itself instead of meandering around. Consider these the equivalent of an "elevator pitch". Thanks, - vijay ___ alto mailing list alto@ietf.org<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto -- -- = | Y. Richard Yang mailto:y...@cs.yale.edu>> | | P
