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 抄送: alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 主题: 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" Sent Time:2021-03-04 22:21:06 (Thursday) To: "kai...@scu.edu.cn" Cc: "alto-cha...@ietf.org" , "alto-...@ietf.org" , "IETF ALTO" 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 抄送: IETF ALTO ; alto-cha...@ietf.org; alto-...@ietf.org 主题: Re: [alto] ALTO Draft ReCharter WG review Dear all, Below are some comments on the 2nd item in the recharter text. As far as I know, the ALTO incremental update extension (RFC 8895) already provides a mechanism to enable the "pub-sub" of ALTO information, using Server-Sent Events (SSE). I see there are multiple directions indicated by the new charter item: [Qin]: Thanks for clarifying the difference between SSE and pub sub proposed in the new proposed charter item. 1. Decouple the "pub-sub" protocol with the underlying mechanism. Besides SSE, other mechanisms can also be used to realize the "pub-sub" of ALTO information, such as HTTP/2, HTTP/3 or the methods mentioned in the charter text. Thus, a direct extension is to define the abstract format of control messages and data messages (i.e., WHAT information should be provided but not HOW), and allow different underlying protocols to use protocol-specific encodings. For example, SSE encodes the metadata (e.g., content-type and stream id) and the content of an event using "event:" and "data:" prefixes at the beginning of each line, and uses empty lines to indicate the end of a message, while HTTP/2 (RFC 7540) may encode the metadata and the content of an event using PUSH_PROMISE/HEADERS and DATA frame . [Qin]: Good analysis, I think we need to decide whether we should define generic pub sub mechanism or transport specific pub sub mechanism. Do you have any suggestion on this? [KAI]: I think the generic pub-sub mechanism (or maybe the term framework is more appropriate) is more important at this point, which should also cover the direction of
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" Sent Time:2021-03-04 22:21:06 (Thursday) To: "kai...@scu.edu.cn" Cc: "alto-cha...@ietf.org" , "alto-...@ietf.org" , "IETF ALTO" 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 抄送: IETF ALTO ; alto-cha...@ietf.org; alto-...@ietf.org 主题: Re: [alto] ALTO Draft ReCharter WG review Dear all, Below are some comments on the 2nd item in the recharter text. As far as I know, the ALTO incremental update extension (RFC 8895) already provides a mechanism to enable the "pub-sub" of ALTO information, using Server-Sent Events (SSE). I see there are multiple directions indicated by the new charter item: [Qin]: Thanks for clarifying the difference between SSE and pub sub proposed in the new proposed charter item. 1. Decouple the "pub-sub" protocol with the underlying mechanism. Besides SSE, other mechanisms can also be used to realize the "pub-sub" of ALTO information, such as HTTP/2, HTTP/3 or the methods mentioned in the charter text. Thus, a direct extension is to define the abstract format of control messages and data messages (i.e., WHAT information should be provided but not HOW), and allow different underlying protocols to use protocol-specific encodings. For example, SSE encodes the metadata (e.g., content-type and stream id) and the content of an event using "event:" and "data:" prefixes at the beginning of each line, and uses empty lines to indicate the end of a message, while HTTP/2 (RFC 7540) may encode the metadata and the content of an event using PUSH_PROMISE/HEADERS and DATA frame . [Qin]: Good analysis, I think we need to decide whether we should define generic pub sub mechanism or transport specific pub sub mechanism. Do you have any suggestion on this? [KAI]: I think the generic pub-sub mechanism (or maybe the term framework is more appropriate) is more important at this point, which should also cover the direction of providing more fine-grained control. One thing that just strikes me after taking a quick look at rabbitMQ is that "pub/sub" means different things in different contexts. It is important we understand what are the requirements of generic pub/sub in the ALTO framework. [KAI]: When we discuss "pub/sub" with SSE and HTTP/2, which is a one-to-one client-server communication, the focus of the "pub/sub" here is simple: what are the messages and how the client can control the subscribed information. However, with message queues (e.g., rabbitMQ), the communication pattern may be more complex: a message can be sent to multiple queues without knowing exactly who is subscribing. I see two ways to realize the more complex "pub/sub" requirement for ALTO information. rabbitMQ: https://www.rabbitmq.com/tutorials/tutorial-three-python.html [KAI]: CASE A: First, the client application may use deploy its own "pub/sub" system, and the ALTO client simply serves as a producer by forwarding the ALTO messages to the "pub/sub" system. In this way, the problem is reduced to the one-to-one "pub/sub" problem. [KAI]: CASE B: Second, ALTO servers may natively support the "pub/sub" of ALTO information. In this case, an ALTO server may need to handle events such as join/leave of clients that subscribe to the same ALTO information. For example, for a client that just subscribes to a network map, the server should send the whole map instead of incremental updates. [KAI]: Both approaches have pros and cons. The first is simple on the server side but may be less efficient (because of trian
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: <mailto:ligan...@chinamobile.com> Li Gang Date: 2020-10-29 18:02 To: <mailto:chunshxi...@tencent.com> chunshxiong(熊春山); <mailto:y...@cs.yale.edu> 'Y. Richard Yang'; <mailto:alto@ietf.org> 'IETF ALTO' 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&depolyment 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. 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) whic
Re: [alto] ALTO recharter to support cellular network use cases
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. 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. 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 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
