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
Hi Richard, Thanks for your thoughts. This is definitely the path we want to take together with a flexible design to encode and represent information carried by Ve. Meet you virtually at the ALTO session Cheers, Sabine From: Y. Richard Yang Sent: Thursday, March 11, 2021 10:29 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Cc: Qin Wu ; IETF ALTO ; alto-cha...@ietf.org; alto-...@ietf.org Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes 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 “Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response” (GPE for short) , I would like to add the following: This work item can be useful, among others, to allow a UE getting cellular network KPIs from an ALTO Server, to figure out for example whether the cell is congested, or which cell to choose. An ALTO Server cannot provide real-time information. With the proposed extensions, it can indicate a number of real-time network parameters against which ALTO cost values can be modulated. [Qin]: Yes, the current ALTO server can only provide non-real time or near real time information, performance metrics work allows ALTO server expose performance data. If ALTO protocol is extended to support pub sub mechanism, Providing real time information will not be an issue. But I agree in many cases, providing real time information is not necessary, e.g., cloud gaming use case provided Tencent and china mobile, their case is different from your proposed case, they will use cloud gaming server as ALTO client to get needed information. [ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated with a cloud gaming server (CGS for short) . In that case, the ALTO information provided by the ALTO Server (AOS for short) can be made aware of given specific parameters captured by the CGS at a different pace. This may speed up the process as well. These parameters are received by UEs directly from the network and not from ALTO. The UE receives an array of ALTO cell KPI values that each depend on the value of a parameter. The UE can pick the ALTO value corresponding to the value of the real-time parameter received from the network. Thus, the UE modulates the received ALTO values in real-time. [Qin]: your case is UE centric solution, UE gets network KPI from ALTO server and get real time parameter from another data source in the Network, what is not clear is how real time parameter is correlated with Network KPI information within UE. Also the interface between UE and RAN is not in the scope of ALTO work, I think.
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
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
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) wrote: > Hi Qin, > > > > Please see inline, > > Thanks > > Sabine > > > > *From:* Qin Wu > *Sent:* Thursday, March 11, 2021 9:32 AM > *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) < > sabine.randriam...@nokia-bell-labs.com>; IETF ALTO > *Cc:* alto-cha...@ietf.org; 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 ; IETF ALTO > *抄送**:* alto-cha...@ietf.org; alto-...@ietf.org > *主题**:* RE: ALTO Draft ReCharter WG review - extensible set of policy > attributes > > > > Hello ALTO WG, > > > > Regarding the proposed work item on “Protocol extensions to support a > richer and extensible set of policy attributes in ALTO information update > request and response” (GPE for short) , I would like to add the following: > > > > This work item can be useful, among others, to allow a UE getting cellular > network KPIs from an ALTO Server, to figure out for example whether the > cell is congested, or which cell to choose. > > > > An ALTO Server cannot provide real-time information. With the proposed > extensions, it can indicate a number of real-time network parameters > against which ALTO cost values can be modulated. > > > > [Qin]: Yes, the current ALTO server can only provide non-real time or near > real time information, performance metrics work allows ALTO server expose > performance data. If ALTO protocol is extended to support pub sub mechanism, > > Providing real time information will not be an issue. > > > > But I agree in many cases, providing real time information is not > necessary, e.g., cloud gaming use case provided Tencent and china mobile, > their case is different from your proposed case, they will use cloud gaming > server as ALTO client to get needed information. > > *[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially > integrated with a cloud gaming server (CGS for short) . In that case, the > ALTO information provided by the ALTO Server (AOS for short) can be made > aware of given specific parameters captured by the CGS at a different pace. > This may speed up the process as well. * > > > > These parameters are received by UEs directly from the network and not > from ALTO. The UE receives an array of ALTO cell KPI values that each > depend on the value of a parameter. The UE can pick the ALTO value > corresponding to the value of the real-time parameter received from the > network. Thus, the UE modulates the received ALTO values in real-time. > > > > [Qin]: your case is UE centric solution, UE gets network KPI from ALTO > server and get real time parameter from another data source in the Network, > what is not clear is how real time parameter is correlated with Network KPI > information within UE. > > Also the interface between UE and RAN is not in the scope of ALTO work, I > think. > > *[ [SR] ] definitely, the scope of the extension restricts to exchanges > between AOS and AOC. The UE may have some agent that gathers and relates > the RAN indicators and the ALTO information and passes the relevant costs > to the application client. Again this agent is out of scope of ALTO. * > > > > This use-case is illust
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
Hi Qin, To my knowledge, ALTO is not expected to provide real-time information. On the other hand is it very useful to convey abstracted information covering cellular networks and beyond, starting with edge. So an ALTO Server may want to approach real-time information but cannot commit to it. This all depends on the covered network scope and level of network information aggregation or abstraction and other factors that may be looked at within the scope of the ALTO operation automation WI. To help an ALTO Client needing near-instant information, the ALTO Server may indicate the available levels of information “freshness” or length of validity intervals with policy attributes that can be used by the Client in its ALTO request. Sabine From: Qin Wu Sent: Thursday, March 11, 2021 11:41 AM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ; IETF ALTO Cc: alto-cha...@ietf.org; alto-...@ietf.org Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes Sabine: Thanks for your clarification, I want to make sure the ALTO clients can express to the ALTO sever that they want real time data or not real time data. Also Alto server can express that the returned information is real time or not real time in the response message to the ALTO clients. Are these covered by your case as well? _Qin 发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) [mailto:sabine.randriam...@nokia-bell-labs.com] 发送时间: 2021年3月11日 18:01 收件人: 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 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 “Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response” (GPE for short) , I would like to add the following: This work item can be useful, among others, to allow a UE getting cellular network KPIs from an ALTO Server, to figure out for example whether the cell is congested, or which cell to choose. An ALTO Server cannot provide real-time information. With the proposed extensions, it can indicate a number of real-time network parameters against which ALTO cost values can be modulated. [Qin]: Yes, the current ALTO server can only provide non-real time or near real time information, performance metrics work allows ALTO server expose performance data. If ALTO protocol is extended to support pub sub mechanism, Providing real time information will not be an issue. But I agree in many cases, providing real time information is not necessary, e.g., cloud gaming use case provided Tencent and china mobile, their case is different from your proposed case, they will use cloud gaming server as ALTO client to get needed information. [ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated with a cloud gaming server (CGS for short) . In that case, the ALTO information provided by the ALTO Server (AOS for short) can be made aware of given specific parameters captured by the CGS at a different pace. This may speed up the process as well. These parameters are received by UEs directly from the network and not from ALTO. The UE receives an array of ALTO cell KPI values that each depend on the value of a parameter. The UE can pick the ALTO value corresponding to the value of the real-time parameter received from the network. Thus, the UE modulates the received ALTO values in real-time. [Qin]: your case is UE centric solution, UE gets network KPI from ALTO server and get real time parameter from another data source in the Network, what is not clear is how real time parameter is correlated with Network KPI information within UE. Also the interface between UE and RAN is not in the scope of ALTO work, I think. [ [SR] ] definitely, the scope of the extension restricts to exchanges between AOS and AOC. The UE may have some agent that gathers and relates the RAN indicators and the AL
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
Sabine: Thanks for your clarification, I want to make sure the ALTO clients can express to the ALTO sever that they want real time data or not real time data. Also Alto server can express that the returned information is real time or not real time in the response message to the ALTO clients. Are these covered by your case as well? _Qin 发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) [mailto:sabine.randriam...@nokia-bell-labs.com] 发送时间: 2021年3月11日 18:01 收件人: Qin Wu ; IETF ALTO 抄送: alto-cha...@ietf.org; alto-...@ietf.org 主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes 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 “Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response” (GPE for short) , I would like to add the following: This work item can be useful, among others, to allow a UE getting cellular network KPIs from an ALTO Server, to figure out for example whether the cell is congested, or which cell to choose. An ALTO Server cannot provide real-time information. With the proposed extensions, it can indicate a number of real-time network parameters against which ALTO cost values can be modulated. [Qin]: Yes, the current ALTO server can only provide non-real time or near real time information, performance metrics work allows ALTO server expose performance data. If ALTO protocol is extended to support pub sub mechanism, Providing real time information will not be an issue. But I agree in many cases, providing real time information is not necessary, e.g., cloud gaming use case provided Tencent and china mobile, their case is different from your proposed case, they will use cloud gaming server as ALTO client to get needed information. [ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated with a cloud gaming server (CGS for short) . In that case, the ALTO information provided by the ALTO Server (AOS for short) can be made aware of given specific parameters captured by the CGS at a different pace. This may speed up the process as well. These parameters are received by UEs directly from the network and not from ALTO. The UE receives an array of ALTO cell KPI values that each depend on the value of a parameter. The UE can pick the ALTO value corresponding to the value of the real-time parameter received from the network. Thus, the UE modulates the received ALTO values in real-time. [Qin]: your case is UE centric solution, UE gets network KPI from ALTO server and get real time parameter from another data source in the Network, what is not clear is how real time parameter is correlated with Network KPI information within UE. Also the interface between UE and RAN is not in the scope of ALTO work, I think. [ [SR] ] definitely, the scope of the extension restricts to exchanges between AOS and AOC. The UE may have some agent that gathers and relates the RAN indicators and the ALTO information and passes the relevant costs to the application client. Again this agent is out of scope of ALTO. This use-case is illustrated in the slides presented at the previous IETF 109 ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and ALTO request and response can be found in slides 7 and 8. Any feedback is more than welcome, (1) https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00 Thanks, Sabine From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Qin Wu Sent: Monday, February 22, 2021 2:51 PM To: IETF ALTO mailto:alto@ietf.org>> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org> Subject: [alto] ALTO Draft ReCharter WG review Hi, : We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC). The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110. To get this goal, an updated inline draft charter text fo
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
Hi Qin, Please see inline, Thanks Sabine From: Qin Wu Sent: Thursday, March 11, 2021 9:32 AM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ; IETF ALTO Cc: alto-cha...@ietf.org; 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 “Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response” (GPE for short) , I would like to add the following: This work item can be useful, among others, to allow a UE getting cellular network KPIs from an ALTO Server, to figure out for example whether the cell is congested, or which cell to choose. An ALTO Server cannot provide real-time information. With the proposed extensions, it can indicate a number of real-time network parameters against which ALTO cost values can be modulated. [Qin]: Yes, the current ALTO server can only provide non-real time or near real time information, performance metrics work allows ALTO server expose performance data. If ALTO protocol is extended to support pub sub mechanism, Providing real time information will not be an issue. But I agree in many cases, providing real time information is not necessary, e.g., cloud gaming use case provided Tencent and china mobile, their case is different from your proposed case, they will use cloud gaming server as ALTO client to get needed information. [ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated with a cloud gaming server (CGS for short) . In that case, the ALTO information provided by the ALTO Server (AOS for short) can be made aware of given specific parameters captured by the CGS at a different pace. This may speed up the process as well. These parameters are received by UEs directly from the network and not from ALTO. The UE receives an array of ALTO cell KPI values that each depend on the value of a parameter. The UE can pick the ALTO value corresponding to the value of the real-time parameter received from the network. Thus, the UE modulates the received ALTO values in real-time. [Qin]: your case is UE centric solution, UE gets network KPI from ALTO server and get real time parameter from another data source in the Network, what is not clear is how real time parameter is correlated with Network KPI information within UE. Also the interface between UE and RAN is not in the scope of ALTO work, I think. [ [SR] ] definitely, the scope of the extension restricts to exchanges between AOS and AOC. The UE may have some agent that gathers and relates the RAN indicators and the ALTO information and passes the relevant costs to the application client. Again this agent is out of scope of ALTO. This use-case is illustrated in the slides presented at the previous IETF 109 ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and ALTO request and response can be found in slides 7 and 8. Any feedback is more than welcome, (1) https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00 Thanks, Sabine From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Qin Wu Sent: Monday, February 22, 2021 2:51 PM To: IETF ALTO mailto:alto@ietf.org>> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org> Subject: [alto] ALTO Draft ReCharter WG review Hi, : We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC). The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110. To get this goal, an updated inline draft charter text for ALTO has just been posted to this list, This charter has received a couple of rounds of informal review from WG members, chairs and our Ads from brief to deep thorough, 5 new chartered items have been listed. We would like to solicit feedback on these new chartered items and your use case, deployment, idea corresponding to these new chartered items. Sharing your past deployment story will also be appreciated. The ALTO working group was established in 2008 to devise a request/response protocol to allow a host to benefit from a server that is more cognizant of the network infrastructure than the host is. The working group has developed an HTTP-based protocol and recent work has reporte
Re: [alto] 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 ; IETF ALTO 抄送: alto-cha...@ietf.org; alto-...@ietf.org 主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes Hello ALTO WG, Regarding the proposed work item on “Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response” (GPE for short) , I would like to add the following: This work item can be useful, among others, to allow a UE getting cellular network KPIs from an ALTO Server, to figure out for example whether the cell is congested, or which cell to choose. An ALTO Server cannot provide real-time information. With the proposed extensions, it can indicate a number of real-time network parameters against which ALTO cost values can be modulated. [Qin]: Yes, the current ALTO server can only provide non-real time or near real time information, performance metrics work allows ALTO server expose performance data. If ALTO protocol is extended to support pub sub mechanism, Providing real time information will not be an issue. But I agree in many cases, providing real time information is not necessary, e.g., cloud gaming use case provided Tencent and china mobile, their case is different from your proposed case, they will use cloud gaming server as ALTO client to get needed information. These parameters are received by UEs directly from the network and not from ALTO. The UE receives an array of ALTO cell KPI values that each depend on the value of a parameter. The UE can pick the ALTO value corresponding to the value of the real-time parameter received from the network. Thus, the UE modulates the received ALTO values in real-time. [Qin]: your case is UE centric solution, UE gets network KPI from ALTO server and get real time parameter from another data source in the Network, what is not clear is how real time parameter is correlated with Network KPI information within UE. Also the interface between UE and RAN is not in the scope of ALTO work, I think. This use-case is illustrated in the slides presented at the previous IETF 109 ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and ALTO request and response can be found in slides 7 and 8. Any feedback is more than welcome, (1) https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00 Thanks, Sabine From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Qin Wu Sent: Monday, February 22, 2021 2:51 PM To: IETF ALTO mailto:alto@ietf.org>> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org> Subject: [alto] ALTO Draft ReCharter WG review Hi, : We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC). The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110. To get this goal, an updated inline draft charter text for ALTO has just been posted to this list, This charter has received a couple of rounds of informal review from WG members, chairs and our Ads from brief to deep thorough, 5 new chartered items have been listed. We would like to solicit feedback on these new chartered items and your use case, deployment, idea corresponding to these new chartered items. Sharing your past deployment story will also be appreciated. The ALTO working group was established in 2008 to devise a request/response protocol to allow a host to benefit from a server that is more cognizant of the network infrastructure than the host is. The working group has developed an HTTP-based protocol and recent work has reported large-scale deployment of ALTO based solutions supporting applications such as content distribution networks (CDN). ALTO is now proposed as a component for cloud-based interactive applications, large-scale data analytics, multi-cloud SD-WAN deployment, and distributed computing. In all these cases, exposing network information such as abstract topologies and network function deployment location helps applications. To support these emerging uses, extensions are needed, and additional functional and architectural features need to be considered as follows: o Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response. Such policy attributes may indicate information dependency (e.g., ALTO path-cost/QoS properties with dependency on real-time network indications), optimization criteria (e.g., lowest latency/throughput network performance objective), and constraints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed,
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
Hello ALTO WG, Regarding the proposed work item on "Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response" (GPE for short) , I would like to add the following: This work item can be useful, among others, to allow a UE getting cellular network KPIs from an ALTO Server, to figure out for example whether the cell is congested, or which cell to choose. An ALTO Server cannot provide real-time information. With the proposed extensions, it can indicate a number of real-time network parameters against which ALTO cost values can be modulated. These parameters are received by UEs directly from the network and not from ALTO. The UE receives an array of ALTO cell KPI values that each depend on the value of a parameter. The UE can pick the ALTO value corresponding to the value of the real-time parameter received from the network. Thus, the UE modulates the received ALTO values in real-time. This use-case is illustrated in the slides presented at the previous IETF 109 ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and ALTO request and response can be found in slides 7 and 8. Any feedback is more than welcome, (1) https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00 Thanks, Sabine From: alto On Behalf Of Qin Wu Sent: Monday, February 22, 2021 2:51 PM To: IETF ALTO Cc: alto-cha...@ietf.org; alto-...@ietf.org Subject: [alto] ALTO Draft ReCharter WG review Hi, : We have requested one hour session for ALTO WG meeting in the upcoming IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC). The goal is to boil down ALTO recharter and have consensus on charter contents in IETF 110. To get this goal, an updated inline draft charter text for ALTO has just been posted to this list, This charter has received a couple of rounds of informal review from WG members, chairs and our Ads from brief to deep thorough, 5 new chartered items have been listed. We would like to solicit feedback on these new chartered items and your use case, deployment, idea corresponding to these new chartered items. Sharing your past deployment story will also be appreciated. The ALTO working group was established in 2008 to devise a request/response protocol to allow a host to benefit from a server that is more cognizant of the network infrastructure than the host is. The working group has developed an HTTP-based protocol and recent work has reported large-scale deployment of ALTO based solutions supporting applications such as content distribution networks (CDN). ALTO is now proposed as a component for cloud-based interactive applications, large-scale data analytics, multi-cloud SD-WAN deployment, and distributed computing. In all these cases, exposing network information such as abstract topologies and network function deployment location helps applications. To support these emerging uses, extensions are needed, and additional functional and architectural features need to be considered as follows: o Protocol extensions to support a richer and extensible set of policy attributes in ALTO information update request and response. Such policy attributes may indicate information dependency (e.g., ALTO path-cost/QoS properties with dependency on real-time network indications), optimization criteria (e.g., lowest latency/throughput network performance objective), and constraints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed, diversity and redundancy of paths). o Protocol extensions for facilitating operational automation tasks and improving transport efficiency. In particular, extensions to provide "pub/sub" mechanisms to allow the client to request and receive a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information. Efforts developed in other working groups such as MQTT Publish / Subscribe Architecture, WebSub, Subscription to YANG Notifications will be considered, and issues such as scalability (e.g., using unicast or broadcast/multicast, and periodicity of object updates) should be considered. o The working group will investigate the configuration, management, and operation of ALTO systems and may develop suitable data models. o Extensions to ALTO services to support multi-domain settings. ALTO is currently specified for a single ALTO server in a single administrative domain, but a network may consist of multiple domains and the potential information sources may not be limited to a certain domain. The working group will investigate extending the ALTO framework to (1) specify multi-ALTO-server protocol flow and usage guidelines when an ALTO service involves network paths spanning multiple domains with
