Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail)
Hello Chunchan, Thanks for the clarification. If I understand well: - the cloud gaming server (CGS) needs notifications on QoS CHANGE information. This change would be conveyed by an ALTO Server that abstracts NEF information to the ALTO Client in the CGS. - only QoS CHANGES upon e.g. exceeding some hysteresis threshold are useful because Continuous QoS information is needless and causes signaling overhead. These changes should be reported to the CGS immediately. To this end, ALTO extended pub/sub is needed. - regarding the pace of the notification, I would have a question: Your e-mail says “the cloud gaming server does need the real-time QUICK QOS CHANGE information” and later specifies “Quick QoS Change notification should not be too frequent, the QUICK QoS change notification should be minutes level”. So what frequency does the term “real-time” in the 1rst sentence cover? Maybe I missed something. Definitely minute-level notification is achievable, given the limited size of the topology covered by ALTO in this case. Another question: - the number of possible QoS values Qi are quite limited and this “volatile” and light information would be conveyed with a given channel, say the channel “Ve” mentioned earlier by Richard. - The longer term costs and properties reflecting QoS impacting KPIs such as latency L and throughput T would then be conveyed via ALTO channel “Vs” in an asynchronous way - would the values of these costs and properties be made dependent on the values of Qi? Thanks, Sabine From: chunshxiong(熊春山) Sent: Friday, March 12, 2021 7:38 AM To: Y. Richard Yang ; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Cc: alto-cha...@ietf.org; alto-...@ietf.org; Qin Wu ; IETF ALTO Subject: RE: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail) Hello all, @Randriamasy, Sabine (Nokia - FR/Paris-Saclay)<mailto:sabine.randriam...@nokia-bell-labs.com>, You say “An ALTO Server cannot provide real-time information". I almost agree with your point. But I want the ALTO Server to support very quick notification information to the ALTO Client, if there is a quick change as provided in my other email. I think one goal of ALTO Server is not to provide very frequent notification to the ALTO Client, but If there is some quick or big change, the ALTO Server needs very quickly notify the ALTO Client, just this, not repeated and continuous notify. I think this quick notification is very helpful for the cloud gaming server to adaptive change the coding scheme. But the cloud gaming does not need the ALTO server to repeated notify the current network bitrates. Cloud gaming server needs the change information not the status information. For the cloud gaming sever can “intelligently” detect the slow change information, but it is very hard for the gaming server to detect the quick change in short time (because there is buffer in the client and Server), in such case, if the ALTO server can provide such quick (QoS) change information to the cloud gaming server, the cloud gaming server can quickly change its coding scheme. So, Yes, the cloud gaming server does NOT need the real-time QoS information, but the cloud gaming server does need the real-time QUICK QOS CHANGE information. But, this Quick QoS change (e.g. Alternative QoS profile) is defined to trigger the cloud server to make some changes(e.g. encoding scheme change). It should be avoid to define a QUICK QOS change that does not trigger the cloud server to make any changes. So the real-time frequently reporting the current QOS to the cloud server is really not needed, this repeated and continuous reporting/notification only creates a lot of message loads and no help for the cloud gaming server. Also this Quick QoS Change notification should not be too frequent, the QUICK QoS change notification should be minutes level, i.e. one notification per one minute. In some cases, it is possible that the notification can be several notifications per one minutes, but the average rate should be less than one notification per one minute. BRs, Chunshan Xiong From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Y. Richard Yang Sent: Friday, March 12, 2021 5:29 AM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org>; Qin Wu mailto:bill...@huawei.com>>; IETF ALTO mailto:alto@ietf.org>> Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail) Hi Sabine, Qin, Good discussions. I support the use cases of the design direction. One suggestion is to look at the design in a slightly abstract, general framework. In particular, the abstract framework looks like this to me: - Ve: A set of "volatile" (ephemeral) variables; Ve tends to be
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail)
Hello all, @Randriamasy, Sabine (Nokia - FR/Paris-Saclay)<mailto:sabine.randriam...@nokia-bell-labs.com>, You say “An ALTO Server cannot provide real-time information". I almost agree with your point. But I want the ALTO Server to support very quick notification information to the ALTO Client, if there is a quick change as provided in my other email. I think one goal of ALTO Server is not to provide very frequent notification to the ALTO Client, but If there is some quick or big change, the ALTO Server needs very quickly notify the ALTO Client, just this, not repeated and continuous notify. I think this quick notification is very helpful for the cloud gaming server to adaptive change the coding scheme. But the cloud gaming does not need the ALTO server to repeated notify the current network bitrates. Cloud gaming server needs the change information not the status information. For the cloud gaming sever can “intelligently” detect the slow change information, but it is very hard for the gaming server to detect the quick change in short time (because there is buffer in the client and Server), in such case, if the ALTO server can provide such quick (QoS) change information to the cloud gaming server, the cloud gaming server can quickly change its coding scheme. So, Yes, the cloud gaming server does NOT need the real-time QoS information, but the cloud gaming server does need the real-time QUICK QOS CHANGE information. But, this Quick QoS change (e.g. Alternative QoS profile) is defined to trigger the cloud server to make some changes(e.g. encoding scheme change). It should be avoid to define a QUICK QOS change that does not trigger the cloud server to make any changes. So the real-time frequently reporting the current QOS to the cloud server is really not needed, this repeated and continuous reporting/notification only creates a lot of message loads and no help for the cloud gaming server. Also this Quick QoS Change notification should not be too frequent, the QUICK QoS change notification should be minutes level, i.e. one notification per one minute. In some cases, it is possible that the notification can be several notifications per one minutes, but the average rate should be less than one notification per one minute. BRs, Chunshan Xiong From: alto On Behalf Of Y. Richard Yang Sent: Friday, March 12, 2021 5:29 AM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Cc: alto-cha...@ietf.org; alto-...@ietf.org; Qin Wu ; IETF ALTO Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail) Hi Sabine, Qin, Good discussions. I support the use cases of the design direction. One suggestion is to look at the design in a slightly abstract, general framework. In particular, the abstract framework looks like this to me: - Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small, fast-changing data; - Vs: Another set of records that are stable and indexed by the ephemeral variables; Vs can be large, but stable data. There are two channels from the network to the application: - Channel 1 for Ve - Channel 2 for Vs This definitely is a generic framework supported by some existing use cases including what you presented. In the general framework, Channel 1 can be ALTO or protocol specific. Since it is short and needs low latency, it is more likely to be protocol specific and embedded in some other protocol such as even data path protocols (5G, ECN bits in IP); channel 2 is ALTO. A couple of points to be considered when conducting further design: - One thing we learned from SSE is the consistency between these two channels (or more, as Ve can be carried by multiple channels, etc), and - Document additional use cases beyond the demonstrated use cases. Looking forward to talking to you (virtually) f2f tomorrow. Richard On Thu, Mar 11, 2021 at 5:01 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>> wrote: Hi Qin, Please see inline, Thanks Sabine From: Qin Wu mailto:bill...@huawei.com>> Sent: Thursday, March 11, 2021 9:32 AM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>>; IETF ALTO mailto:alto@ietf.org>> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org> Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes Hi, Sabine: 发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) [mailto:sabine.randriam...@nokia-bell-labs.com] 发送时间: 2021年3月11日 1:55 收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO mailto:alto@ietf.org>> 抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org> 主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes Hello ALTO WG, Regarding the proposed work item on “Protoco
