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
Hi Richard,
Thanks for sharing your idea！ I think it's necessary to considering the
security and privacy issues.
The framework of differential privacy can be a potential choice to protect
individual or detail privacy of network without encryption which might influent
the efficiency of information exchange, while it need to consider the data
availability.
Regards,
Peng
Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105
email: liupeng...@chinamobile.com
发件人: Y. Richard Yang
时间: 2021/03/10(星期三)10:32
收件人: Qiao Xiang;
抄送人: 刘鹏;IETF ALTO;Qin Wu;
主题: Re: [alto] ALTO Draft ReCharter WG review
Hi Peng, all,
Thanks a lot for the excellent discussions. It is clear that multi-domain is a
major issue to resolve, as multidomain is the general deployment setting where
resource consumers and providers are in the general case deployed in multiple
networks.
To proceed with the recharter discussion, I suggest that we conduct basic
security and privacy analysis to see if we are ready for recharter; that is, we
have a basic understanding of related issues so that it is ready for design,
not still in the early research stage. For security, we can start with focusing
on the basic requirements including authenticity, integrity, and
confidentiality. For privacy, we can start with a framework such as
differential privacy analysis.
To me, a basic model of a multi-domain alto information service is the
following:
- a set of (potential) resource providers s1, s2, ...,
- a set of (potential) resource consumers c1, c2, c3, ...
The foundation of the alto service is to provide the costs of the paths {si ->
cj}; I always think of alto as an extension of DNS, which is mainly for
endpoints in a graph and alto is paths. In a single domain setting, all
entities, {si}, {cj}, {si->cj} are within a single domain and hence the main
security/privacy issue is the security/privacy issue of between the single alto
server representing the single domain and the alto client. For security, the
domain can leverage any one of the security systems (e.g., using public keys to
bootstrap the system); for privacy, the application (client) and the network
(server) are two parties, and they can agree on an acceptable privacy model.
Now, in a multi-domain setting, each entity may have a different domain (or a
sequence of domains for a path). Now, both ALTO client and ALTO server will
have additional security and privacy issues.
- For the ALTO client, the information can now come from multiple networks;
assume the information info(n1, n2, ...) is computed from those from multiple
networks n1, n2, ... Then the basic security issue is how the client can verify
the authenticity of the information.
- For an ALTO server, the server may not have a direct trust relationship with
the client; for example, when the ALTO server is only in the chain of a path,
not the client-facing server. Hence, the server may not have a relationship to
specify the privacy requirement.
The preceding are challenging issues. It is clear that security and privacy
issues depend on the specific design. Hence, we target a "lower-bound"
analysis, by considering a base design that can address main security and
privacy issues. The WG can decide on the specific design which is better than
the basic design.
During the design meetings, we have considered the following "base-line" design
for a "lower-bound":
- We provide a basic path discovery service to discover the path segments. We
can use BGP security to bootstrap the security of the discovered paths.
- We build verifiable aggregation (i.e., the preceding info function) so that
the information can then be individually verified.
- The remaining issue is how each server can control the privacy of its
information, as it may not have a direct relationship with the client. For
this, we suggest to start with basic public information, and gradually build
trust.
The preceding is high level. A first task, if multidomain is charted, is to
write down the details, beyond the existing drafts. I do agree that this
analysis and requirements is a good starting, based on the specified use cases.
We can go over the details in our design meeting in the next few following
weeks.
Richard
On Tue, Mar 2, 2021 at 11:18 AM Qiao Xiang wrote:
Hi Peng, Qin and Richard,
Very good discussion! Richard and I have been working with folks from CMS and
ESNet (a large global multi-domain science network) to design network
information exposure abstractions and mechanisms in multi-domain networks, with
privacy requirements considered. The basic idea stems from the ALTO path-vector
extension but goes beyond to take privacy into consideration. The following are
some pointers.
[1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network
Reso
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
rated 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 multiple ALTO servers, and (2) extend or introduce ALTO > > services allowing east-west interfaces for multiple ALTO server > integration and collaboration. The specifications and extensions should use > existing services whenever possible. The specifications and extensions > should consider realistic complexities including incremental deployment, > dynamicity, and security issues such as access control, authorization > (e.g., an ALTO s
Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes
TO 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 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 multiple ALTO servers, and (2) extend or introduce ALTO services allowing east-west interfaces for multiple ALTO server integration and collaboration. The specifications and extensions should use existing services whenever possible. The specifications and extensions should consider realistic complexities including incremental deployment, dynamicity, and security issues such as access control, authorization (e.g., an ALTO server provides information for a network that the server has no authorization), and privacy protection in multi-domain settings. o The working group will update RFC 7971 to provide operational considerations for recent protocol extensions (e.g., cost calendar, unified properties, and
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 spann
Re: [alto] ALTO Draft ReCharter WG review
eeexplore.ieee.org/abstract/document/8756056) >> [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed >> Data Analytics", ( >> https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/) >> >> For the pointers above, the privacy requirement considered in this work >> is that the network information of multiple domains should be exposed to >> applications as a complete, unified aggregation, appearing as much as >> possible as from a single (virtual) network. We design a network >> information obfuscation mechanism so that the application is not able to >> associate any network resource bottleneck information to any domain, >> reducing the risk of exposing network vulnerability. >> >> In addition, we also studied how to control the routing across multiple >> domains to achieve more flexible end-to-end interdomain routing. >> Essentially, we propose a mechanism that allows networks to expose their >> available interdomain routes, just as BGP looking glasses, so that >> applications can control them. In this setting, we consider the privacy >> setting where each network's BGP export policies are private, and design >> interesting algorithms for applications to select the best policy-compliant >> routes without knowing the export policies. The following is the pointer >> for this study: >> >> [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 ( >> https://ieeexplore.ieee.org/abstract/document/9155486) >> >> Above are our current efforts on extending ALTO to multi-domain settings. >> It would be great if we can know more about the industry efforts on network >> information exposure in multi-domain settings, and the privacy requirements >> of operators. This would be extremely helpful to push this extension >> forward! :-) >> >> >> >> Best >> Qiao >> >> On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 wrote: >> >>> Hi Richard, >>> >>> Thank you. please see my reply inline below. >>> >>> >>> Peng Liu | 刘鹏 >>> China Mobile | 移动研究院 >>> mobile phone：13810146105 >>> email: * liupeng...@chinamobile.com * >>> >>> >>> 发件人: Y. Richard Yang >>> 时间: 2021/03/02(星期二)07:36 >>> 收件人: 刘鹏 ; >>> 抄送人: IETF ALTO ;Qin Wu ; >>> 主题: Re: [alto] ALTO Draft ReCharter WG review >>> >>> Dear Peng, >>> >>> Thank you so much for the feedback. Please see below. >>> >>> On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 wrote: >>> >>>> Hi WG, >>>> >>>> >>>> Here are some considerations of recharter: >>>> >>>> I believe that the multi domain problem is worthy of attention. >>>> >>> >>> It is good info. >>> >>> >>>> At present, operators also research in it, which may involve >>>> guaranteeing end-to-end network service in the future, such as delay, >>>> bandwidth, etc. There are some researches on cross domain deterministic >>>> network in the industry, which need some support from management and >>>> control plane. >>>> >>> >>> Do you want to share some pointers? >>> >>> [Peng] As Qin said, it is hard to collect information across network >>> borders. >>> >>> Just taking deterministic network as an example, it is hard to applying >>> synchronization, unified forwarding strategy in multi domain, so there >>> are some works need to be done with management plane. Due to the large >>> scale and multi domains or operators, the management system may be >>> distributed. >>> >>> A potential way is to consider negotiating the forwarding time of each >>> domain in advance and carrying time stamp in the message to control the >>> forwarding path of each domain. While it needs some agreements like >>> contracts to prevent one party from tampering with and denying the >>> management content. >>> >>> Beside this, there may be others use case. I'm not sure if Alto servers >>> are willing to do those work, but it may be helpful to collect or configure >>> some key information. >>> >>> Who is the provider of Alto service is related to the deployment and >>>> cooperation mode. It may be difficult for operators to give too much >>>> detailed network information now. If the Alto service belongs to the >>>> operator, it may be used to help manage its own network. If Alt
Re: [alto] ALTO Draft ReCharter WG review(Internet mail)
Hello Qin, Normally, the 1080p/720p indicates the bitrates. The cloud gaming server only provides the bitrate span to the ALTO server( to the 5G network), it does not need to provide the encoding scheme information to the 5G network. Normally we/Tencent use H.264 encoding scheme because there are a lot of open source available, but some vide streaming service are testing to use VP8 encoding scheme to compare the performance between different encoding scheme. But H.264 is used in most video streaming. BRs, Chunshan Xiong From: alto On Behalf Of Qin Wu Sent: Monday, March 8, 2021 3:03 PM 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(Internet mail) Thanks for your clarification, I think 1080p and 720p are resolution, corresponding to HD, SD video, or 4.5Mbit/s, 2.5 Mbit/s bit rate if you are using H.264 encoding scheme. Have you considered to use VP8 encoding scheme? -Qin 发件人: Li Gang [mailto:ligan...@chinamobile.com] 发送时间: 2021年3月8日 11:42 收件人: Qin Wu mailto:bill...@huawei.com>>; kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> 抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org>; 'IETF ALTO' mailto:alto@ietf.org>> 主题: 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<mailto:kai...@scu.edu.cn> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto: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<mailto:kai...@scu.edu.cn>; Qin Wu mailto:bill...@huawei.com>> 抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org>; 'IETF ALTO' mailto:alto@ietf.org>> 主题: 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<mailto:kai...@scu.edu.cn> Sent: Friday, March 5, 2021 11:03 AM To: Qin Wu Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto: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" mailto:bill...@huawei.com>> Sent Time:2021-03-04 22:21:06 (Thursday) To: "kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>" mailto:kai...@scu.edu.cn>> Cc: "alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>" mailto:alto-cha...@ietf.org>>, "alto-...@ietf.org<mailto:alto-...@ietf.org>" mailto:alto-...@ietf.org>>, "IETF ALTO" mailto:alto@ietf.org>> Subject: Re: [
Re: [alto] ALTO Draft ReCharter WG review
tleneck information to any domain, > reducing the risk of exposing network vulnerability. > > In addition, we also studied how to control the routing across multiple > domains to achieve more flexible end-to-end interdomain routing. > Essentially, we propose a mechanism that allows networks to expose their > available interdomain routes, just as BGP looking glasses, so that > applications can control them. In this setting, we consider the privacy > setting where each network's BGP export policies are private, and design > interesting algorithms for applications to select the best policy-compliant > routes without knowing the export policies. The following is the pointer > for this study: > > [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 ( > https://ieeexplore.ieee.org/abstract/document/9155486) > > Above are our current efforts on extending ALTO to multi-domain settings. > It would be great if we can know more about the industry efforts on network > information exposure in multi-domain settings, and the privacy requirements > of operators. This would be extremely helpful to push this extension > forward! :-) > > > > Best > Qiao > > On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 wrote: > >> Hi Richard, >> >> Thank you. please see my reply inline below. >> >> >> Peng Liu | 刘鹏 >> China Mobile | 移动研究院 >> mobile phone：13810146105 >> email: * liupeng...@chinamobile.com * >> >> >> 发件人: Y. Richard Yang >> 时间: 2021/03/02(星期二)07:36 >> 收件人: 刘鹏 ; >> 抄送人: IETF ALTO ;Qin Wu ; >> 主题: Re: [alto] ALTO Draft ReCharter WG review >> >> Dear Peng, >> >> Thank you so much for the feedback. Please see below. >> >> On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 wrote: >> >>> Hi WG, >>> >>> >>> Here are some considerations of recharter: >>> >>> I believe that the multi domain problem is worthy of attention. >>> >> >> It is good info. >> >> >>> At present, operators also research in it, which may involve >>> guaranteeing end-to-end network service in the future, such as delay, >>> bandwidth, etc. There are some researches on cross domain deterministic >>> network in the industry, which need some support from management and >>> control plane. >>> >> >> Do you want to share some pointers? >> >> [Peng] As Qin said, it is hard to collect information across network >> borders. >> >> Just taking deterministic network as an example, it is hard to applying >> synchronization, unified forwarding strategy in multi domain, so there >> are some works need to be done with management plane. Due to the large >> scale and multi domains or operators, the management system may be >> distributed. >> >> A potential way is to consider negotiating the forwarding time of each >> domain in advance and carrying time stamp in the message to control the >> forwarding path of each domain. While it needs some agreements like >> contracts to prevent one party from tampering with and denying the >> management content. >> >> Beside this, there may be others use case. I'm not sure if Alto servers >> are willing to do those work, but it may be helpful to collect or configure >> some key information. >> >> Who is the provider of Alto service is related to the deployment and >>> cooperation mode. It may be difficult for operators to give too much >>> detailed network information now. If the Alto service belongs to the >>> operator, it may be used to help manage its own network. If Alto service >>> belong to non operators, I think the issue of how to cooperate needs >>> further discussion. >>> >>> >>> It looks that you want to consider both modes: multidomains but single >> operator (i.e., intra-cooperation) and multidomains and multiple operators. >> Regardless, I agree that it is important for the work to clarify on the >> privacy requirements. >> >> [Peng] Yes, agree. >> >> Richard >> >> >> >> >>> Regards, >>> >>> Peng >>> >>> Peng Liu | 刘鹏 >>> China Mobile | 移动研究院 >>> mobile phone：13810146105 >>> email: * liupeng...@chinamobile.com * >>> >>> >>> 发件人: Qin Wu >>> 时间: 2021/02/22(星期一)21:45 >>> 收件人: IETF ALTO ; >>> 抄送人: alto-chairs ;alto-ads ; >>> 主题: [alto] ALTO Draft ReCharter WG review >>> >>> Hi, : >>> >>> We have requested one hour session for ALTO WG meet
Re: [alto] ALTO Draft ReCharter WG review
Hi, Kai: 发件人: alto [mailto:alto-boun...@ietf.org] 代表 kai...@scu.edu.cn 发送时间: 2021年3月8日 17:44 收件人: Qin Wu 抄送: alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 主题: Re: [alto] ALTO Draft ReCharter WG review Hi Gang and Qin, I am also interested in the details of the use case. Like I mentioned, ALTO already has an extension (RFC 8895) that allows one-to-one pub/sub, it would be useful if the use case can show that the current design, despite that it is built on top of SSE, is not enough to support similar common use cases. My guess is that there are some synchronization requirements that the subscribers are intended to make decisions based on the same ALTO information? So aside from Qin's question on the traffic pattern, it would be wonderful if the use case can illustrate the distribution of ALTO information. [Qin]: Good point, When NETCONF WG is talking about their next step or new work last night, NETCONF over HTTP 2/ HTTP 3 had been brought up and got a lot of attention. Therefore I think it will be valuable for us to investigate how ALTO can migrate transport from HTTP 1.0 to HTTP 2/HTTP3 and leverage underlying capability as well. One question come up from NETCONF discussion, is whether NETCONF should allocate new port for new transport. I am not sure this issue applies to ALTO protocol as well. I am also a bit confused about what one-time subscription means here. Is it one-time for a single subscriber or multiple subscribers? If for a single subscriber, I do not see why the subscriber would make the same subscription many times. It would wonderful if we can clarify this in the use case. [Qin]:I believe it is terminology issue, I think we can have on demand subscription, and periodical subscription. One time subscription is similar to on demand subscription. Refer to gNMI for the similar term (https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#35-subscribing-to-telemetry-updates): " A client may create a subscription which has a dedicated stream to return one-off data (ONCE); a subscription that utilizes a stream to periodically request a set of data (POLL); or a long-lived subscription that streams data according to the triggers specified within the individual subscription's mode (STREAM). " Best, Kai -Original Messages- From:"Qin Wu" mailto:bill...@huawei.com>> Sent Time:2021-03-08 10:51:31 (Monday) To: "Li Gang" mailto:ligan...@chinamobile.com>>, "kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>" mailto:kai...@scu.edu.cn>> Cc: "alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>" mailto:alto-cha...@ietf.org>>, "alto-...@ietf.org<mailto:alto-...@ietf.org>" mailto:alto-...@ietf.org>>, "'IETF ALTO'" mailto:alto@ietf.org>> 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. Can you clarify a little bit about specific application traffic patterns? 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<mailto:kai...@scu.edu.cn>; Qin Wu mailto:bill...@huawei.com>> 抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org>; 'IETF ALTO' mailto:alto@ietf.org>> 主题: 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<mailto:kai...@scu.edu.cn> Sent: Friday, March 5, 2021 11:03 AM To: Qin Wu Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto: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 differe
Re: [alto] ALTO Draft ReCharter WG review
Hi Gang and Qin, I am also interested in the details of the use case. Like I mentioned, ALTO already has an extension (RFC 8895) that allows one-to-one pub/sub, it would be useful if the use case can show that the current design, despite that it is built on top of SSE, is not enough to support similar common use cases. My guess is that there are some synchronization requirements that the subscribers are intended to make decisions based on the same ALTO information? So aside from Qin's question on the traffic pattern, it would be wonderful if the use case can illustrate the distribution of ALTO information. I am also a bit confused about what one-time subscription means here. Is it one-time for a single subscriber or multiple subscribers? If for a single subscriber, I do not see why the subscriber would make the same subscription many times. It would wonderful if we can clarify this in the use case. Best, Kai -Original Messages- From:"Qin Wu" Sent Time:2021-03-08 10:51:31 (Monday) 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. Can you clarify a little bit about specific application traffic patterns? 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_PROMIS
Re: [alto] ALTO Draft ReCharter WG review
Thanks for your clarification, I think 1080p and 720p are resolution, corresponding to HD, SD video, or 4.5Mbit/s, 2.5 Mbit/s bit rate if you are using H.264 encoding scheme. Have you considered to use VP8 encoding scheme? -Qin 发件人: Li Gang [mailto:ligan...@chinamobile.com] 发送时间: 2021年3月8日 11:42 收件人: Qin Wu ; kai...@scu.edu.cn 抄送: alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 主题: 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<mailto:kai...@scu.edu.cn> Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto: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<mailto:kai...@scu.edu.cn>; Qin Wu mailto:bill...@huawei.com>> 抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto:alto-...@ietf.org>; 'IETF ALTO' mailto:alto@ietf.org>> 主题: 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<mailto:kai...@scu.edu.cn> Sent: Friday, March 5, 2021 11:03 AM To: Qin Wu Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto: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" mailto:bill...@huawei.com>> Sent Time:2021-03-04 22:21:06 (Thursday) To: "kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>" mailto:kai...@scu.edu.cn>> Cc: "alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>" mailto:alto-cha...@ietf.org>>, "alto-...@ietf.org<mailto:alto-...@ietf.org>" mailto:alto-...@ietf.org>>, "IETF ALTO" mailto:alto@ietf.org>> Subject: Re: [alto] ALTO Draft ReCharter WG review Kai: 发件人: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> [mailto:kai...@scu.edu.cn] 发送时间: 2021年3月3日 21:40 收件人: 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] 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
Re: [alto] ALTO Draft ReCharter WG review
Hi Qin, See my comments inline. On Mon, Mar 8, 2021 at 11:21 AM Qin Wu wrote: > Hi, Jensen and Qian: > > Thanks for your clarification, , the interesting paper [2] you share, > > I am wondering how ALTO server in your implementation get network info > from BGP in each domain? > In our implementation, the ALTO server doesn't get network info from the BGP/SFP speaker. Each domain runs OpenFlow to do the intra-domain routing. And the ALTO server gets intra-domain network info from the OpenFlow controller in each domain. The SFP speaker in each domain provides another service to allow the application to request the inter-domain routing. We also inject a delegation service into the ALTO server to delegate such requests to the SFP speaker. But it doesn't follow any existing ALTO specification. > Do you configure ALTO server in each domain for consistent Cost Metric > reporting? What if each ALTO server report different Cost metric in the > multi-domain setting? > Yes, we enforce each domain to deploy the same ALTO server implementation and configure the consistent cost metric reporting. The inconsistent cost metric reporting was not in the scope of our previous work. But personally, if ALTO servers report different cost metrics, I think one potential solution is to design a negotiation mechanism similar to the ethernet link connection negotiation before the client does any ALTO queries. Thanks, Jensen > > > -Qin > > *发件人:* Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com] > *发送时间:* 2021年3月5日 10:26 > *收件人:* Qiao Xiang > *抄送:* Qin Wu ; 刘鹏 ; IETF > ALTO > *主题:* Re: [alto] ALTO Draft ReCharter WG review > > > > Hi Qin and Qiao, > > Please see my comments inline. > > > > On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang wrote: > > Hi Qin, > > > > Thank you so much for the feedback. Please see my responses inline. > > > > On Thu, Mar 4, 2021 at 9:22 PM Qin Wu wrote: > > Thanks Qiao for sharing your project on Unicorn and thought on > multi-domain setting. > > My impression in your implementation is each domain name and first ingress > node in such domain will be carried in the ALTO response message. > > First, for domain name, I do not believe we need that in the ALTO response > message. Our setting here is each domain has an ALTO server, and the ALTO > clients at the aggregator have separate connections to different ALTO > servers. In this way, by maintaining a (domain, ALTO server) mapping, the > aggregator can differentiate responses from different domains. > > > > Right, our implementation didn't carry each domain name in the ALTO > message. The current ALTO protocol cannot carry on this info. And we also > didn't do such an extension to ALTO. We just use a centralized aggregator > (which can be considered as an ALTO client) to coordinate with the ALTO > server of each domain. There is no communication between any two ALTO > servers. The domain name may appear in the configuration message. > > > > Second, for ingress node, the client needs to specify the ingress and the > (srcIP, dstIP) pair in the query first so that the ALTO server knows what > information to return. And I should also clarify that although we use > ODL-ALTO for our system, but the path vector extension is not implemented > exactly following the specification since it was not fully stabilized then. > > > > Yes, and the ingress info only appears in the request message, not in the > response message. We use the early design of the FCS extension [1] to do > this. The request message should specify the flow-id of each flow. > > > > [1] https://tools.ietf.org/html/draft-gao-alto-fcs-04 > > > > > > @Jensen is the core developer and can comment further on this, as well as > the ODL implementation. > > > > One thing I want to highlight is > > Unicorn has already been deployed in several cities of USA in 2018 and > implemented in the ODL open source. > > I should clarify that this deployment is pre-production, and the > demonstration scenario is at SC18 and SC19, where we are at the conference > cities (Dallas and Denver), and orchestrate traffic from there back to a > Caltech LHC site (we manually separate this site into two domains to create > a 3-domain scenario for demonstration purpose.) > > > > Quote from > https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/ > > “ > >The authors build an ALTO server on top of the OpenDaylight Software > >Defined Network controller. The ALTO server collects the network > >state information from the OpenDaylight controller, e.g., topology, > >policy and traffic statistics, processes the collected information > >into resourc
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 providing more fine-
Re: [alto] ALTO Draft ReCharter WG review
Hi, Jensen and Qian: Thanks for your clarification, , the interesting paper [2] you share, I am wondering how ALTO server in your implementation get network info from BGP in each domain? Do you configure ALTO server in each domain for consistent Cost Metric reporting? What if each ALTO server report different Cost metric in the multi-domain setting? -Qin 发件人: Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com] 发送时间: 2021年3月5日 10:26 收件人: Qiao Xiang 抄送: Qin Wu ; 刘鹏 ; IETF ALTO 主题: Re: [alto] ALTO Draft ReCharter WG review Hi Qin and Qiao, Please see my comments inline. On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang mailto:xiang...@gmail.com>> wrote: Hi Qin, Thank you so much for the feedback. Please see my responses inline. On Thu, Mar 4, 2021 at 9:22 PM Qin Wu mailto:bill...@huawei.com>> wrote: Thanks Qiao for sharing your project on Unicorn and thought on multi-domain setting. My impression in your implementation is each domain name and first ingress node in such domain will be carried in the ALTO response message. First, for domain name, I do not believe we need that in the ALTO response message. Our setting here is each domain has an ALTO server, and the ALTO clients at the aggregator have separate connections to different ALTO servers. In this way, by maintaining a (domain, ALTO server) mapping, the aggregator can differentiate responses from different domains. Right, our implementation didn't carry each domain name in the ALTO message. The current ALTO protocol cannot carry on this info. And we also didn't do such an extension to ALTO. We just use a centralized aggregator (which can be considered as an ALTO client) to coordinate with the ALTO server of each domain. There is no communication between any two ALTO servers. The domain name may appear in the configuration message. Second, for ingress node, the client needs to specify the ingress and the (srcIP, dstIP) pair in the query first so that the ALTO server knows what information to return. And I should also clarify that although we use ODL-ALTO for our system, but the path vector extension is not implemented exactly following the specification since it was not fully stabilized then. Yes, and the ingress info only appears in the request message, not in the response message. We use the early design of the FCS extension [1] to do this. The request message should specify the flow-id of each flow. [1] https://tools.ietf.org/html/draft-gao-alto-fcs-04 @Jensen is the core developer and can comment further on this, as well as the ODL implementation. One thing I want to highlight is Unicorn has already been deployed in several cities of USA in 2018 and implemented in the ODL open source. I should clarify that this deployment is pre-production, and the demonstration scenario is at SC18 and SC19, where we are at the conference cities (Dallas and Denver), and orchestrate traffic from there back to a Caltech LHC site (we manually separate this site into two domains to create a 3-domain scenario for demonstration purpose.) Quote from https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/ “ The authors build an ALTO server on top of the OpenDaylight Software Defined Network controller. The ALTO server collects the network state information from the OpenDaylight controller, e.g., topology, policy and traffic statistics, processes the collected information into resource abstraction, and sends the abstraction back to the ALTO client at the resource orchestrator. The Unicorn framework has been deployed and demonstrated in small federation networks connecting Dallas, Texas, Los Angles, California, and Denver, Colorado at different conventions. For example, in 2018, the federation in the demonstration is composed of three member networks. Network 1 is in Dallas, Texas, and Network 2 and network 3 are in Los Angeles, California. Network 1 is connected to network 2 through a layer-2 WAN circuit with a 100 Gbps bandwidth, provisioned by several providers such as SCinet, CenturyLink and CENIC. Network 1 is a temporal science network in the CMS experiment, while network 2 and 3 are long-running CMS Tier-2 sites. ” I believe your case require server to server communication for end-to-end interdomain routing. Yes, the server-to-server communication for the e2e interdomain routing is helpful. However, we didn't use/extend ALTO to do this in our deployment. We used SFP (a BGP extension) [2] to do this. So any ALTO servers didn't communicate with each other. The limitation is that we must assume the ALTO server of each domain can provide consistent cost metrics. [2] "SFP: Toward Interdomain Routing for SDN Networks", SIGCOMM 2018 Poster (https://dl.acm.org/doi/10.1145/3234200.3234207) Thanks, Jensen Secondly, as for network information exposure in multi-domain setting, I think 1. 3GPP Network Exposure Function is a good example f
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. Can you clarify a little bit about specific application traffic patterns? 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<mailto:kai...@scu.edu.cn> Sent: Friday, March 5, 2021 11:03 AM To: Qin Wu Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; alto-...@ietf.org<mailto: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" mailto:bill...@huawei.com>> Sent Time:2021-03-04 22:21:06 (Thursday) To: "kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>" mailto:kai...@scu.edu.cn>> Cc: "alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>" mailto:alto-cha...@ietf.org>>, "alto-...@ietf.org<mailto:alto-...@ietf.org>" mailto:alto-...@ietf.org>>, "IETF ALTO" mailto:alto@ietf.org>> Subject: Re: [alto] ALTO Draft ReCharter WG review Kai: 发件人: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> [mailto:kai...@scu.edu.cn] 发送时间: 2021年3月3日 21:40 收件人: 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] 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-serve
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 Draft ReCharter WG review
Hi Qin, Please see inline. Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com 发件人: Qin Wu 时间: 2021/03/03(星期三)17:11 收件人: 刘鹏; 抄送人: IETF ALTO; 主题: RE: RE: [alto] ALTO Draft ReCharter WG review Hi, Peng: 发件人: 刘鹏 [mailto:liupeng...@chinamobile.com] 发送时间: 2021年3月2日 11:41 收件人: Qin Wu 抄送: IETF ALTO 主题: Re: RE: [alto] ALTO Draft ReCharter WG review Hi Qin, Thanks you. I still have some questions, please see my reply inline below. Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com Hi WG, Here are some considerations of recharter: I believe that the multi domain problem is worthy of attention. At present, operators also research in it, which may involve guaranteeing end-to-end network service in the future, such as delay, bandwidth, etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane. [Qin]: thanks for sharing your use case, I think we may have many multi-domain applications. Multiple domain setting is not only referred to multiple administrative domains belonging to the same operator but also referred to cross operator domains. [Peng]: Yes, we can easily find the usecase of cross operators domains such as home broadband. Detnet can be a good use case for muit-domain setting, we may also consider many other use cases such as traffic from source to destination spanning across multiple administrative domain, the computing and storage are distributed in different administrative domain [Peng]: DetNet WG only solves the problem of single domain, because multi domain brings much more challenge to the deterministic latency guarantee. It may be difficult to implement strict multi domain deterministic latency guarantee now, but we may gradually optimize it. [Qin-1]Yes, you are right, reading Detnet charter, its scope did focuses on single administrative control domain or within a closed group of administrative control domain. I believe RAW WG also focuses on single domain issue. [Peng-1] It is a challenge but valuable I think, we also initiated a work item“Requirements and framework of Deterministic QoS in large-scale telecommunications networking for IMT-2020 networks and beyond" in ITU-T, which includes discussing the multi domain requirments in deterministic network. Which require resource discovery or multi domain SFC case. As stipulated by RFC7971, there is the network consisting of multiple domains and in many cases it is not possible to collect information across network borders. This issue can be addressed by deploying ALTO server in each domain with hierarchy design or mesh design, and allow server to server communication. In addition, we need to consider multi domain connectivity discovery, multi domain service discovery. [Peng]: I agree that it is difficult 'to collect information across network borders', and can you explain more about the "hierarchy design or mesh design"? For the 'multi domain connectivity discovery, multi domain service discovery', is there any usecase or requirements can be found now? [Qin-1]:In hierarchy design, ALTO servers in the domain partitions (e.g., each local domain) gather local information and send it to centralized ALTO server. The mesh design, is more like peer to peer pattern design, ALTO servers may be set up in each domain independently, and gathering the network information from other connected adjacent domains. Multi-domain connectivity discovery, multi service discovery is the solutions proposed for the corresponding use case. multi-service discovery is more related to ALTO server discovery, I think we may leverage existing mechanism proposed in RFC8686. Multi-connectivity discovery is to expand ALTO path vector mechanism to multi domain setting. Special requirements for multi-domain setting is to carry network information across domain which include domain identifier information, we may also consider to carry compute information, which help combine network information and compute information for service edge discovery. [Peng-1] : Good idea and I think it may help the network and benifit some new services in the furture. Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion. [Qin]:I think one good use case we have is MOWIE use case, i.e., adjust the bitrate to improve Cloud gaming QoE experience based on abstract network informatio
Re: [alto] ALTO Draft ReCharter WG review
Hi, 发件人: Qiao Xiang [mailto:xiang...@gmail.com] 发送时间: 2021年3月5日 0:03 收件人: Qin Wu 抄送: 刘鹏 ; Y. Richard Yang ; IETF ALTO 主题: Re: [alto] ALTO Draft ReCharter WG review Sorry, I missed one comment: Qin: I believe your case require server to server communication for end-to-end interdomain routing. My comment: I think we used BGP to provide the e2e interdomain routing information. [Qin Wu]: Understand, we don’t need to change route exchange protocol across domain, BGP is the wonderful protocol for this job. Best Qiao On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang mailto:xiang...@gmail.com>> wrote: Hi Qin, Thank you so much for the feedback. Please see my responses inline. On Thu, Mar 4, 2021 at 9:22 PM Qin Wu mailto:bill...@huawei.com>> wrote: Thanks Qiao for sharing your project on Unicorn and thought on multi-domain setting. My impression in your implementation is each domain name and first ingress node in such domain will be carried in the ALTO response message. First, for domain name, I do not believe we need that in the ALTO response message. Our setting here is each domain has an ALTO server, and the ALTO clients at the aggregator have separate connections to different ALTO servers. In this way, by maintaining a (domain, ALTO server) mapping, the aggregator can differentiate responses from different domains. Second, for ingress node, the client needs to specify the ingress and the (srcIP, dstIP) pair in the query first so that the ALTO server knows what information to return. And I should also clarify that although we use ODL-ALTO for our system, but the path vector extension is not implemented exactly following the specification since it was not fully stabilized then. [Qin Wu]: I think we can use BGP for inter domain route exchange, we can use ALTO path vector for multi-domain peer selection or path selection. Right now, I think path vector hasn’t been designed for multi-domain setting, if my understanding is correct. But PCEP has already supported multi-domain path computation. @Jensen is the core developer and can comment further on this, as well as the ODL implementation. One thing I want to highlight is Unicorn has already been deployed in several cities of USA in 2018 and implemented in the ODL open source. I should clarify that this deployment is pre-production, and the demonstration scenario is at SC18 and SC19, where we are at the conference cities (Dallas and Denver), and orchestrate traffic from there back to a Caltech LHC site (we manually separate this site into two domains to create a 3-domain scenario for demonstration purpose.) [Qin Wu]: I see. Thank Qiao for clarification. Quote from https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/ “ The authors build an ALTO server on top of the OpenDaylight Software Defined Network controller. The ALTO server collects the network state information from the OpenDaylight controller, e.g., topology, policy and traffic statistics, processes the collected information into resource abstraction, and sends the abstraction back to the ALTO client at the resource orchestrator. The Unicorn framework has been deployed and demonstrated in small federation networks connecting Dallas, Texas, Los Angles, California, and Denver, Colorado at different conventions. For example, in 2018, the federation in the demonstration is composed of three member networks. Network 1 is in Dallas, Texas, and Network 2 and network 3 are in Los Angeles, California. Network 1 is connected to network 2 through a layer-2 WAN circuit with a 100 Gbps bandwidth, provisioned by several providers such as SCinet, CenturyLink and CENIC. Network 1 is a temporal science network in the CMS experiment, while network 2 and 3 are long-running CMS Tier-2 sites. ” I believe your case require server to server communication for end-to-end interdomain routing. Secondly, as for network information exposure in multi-domain setting, I think 1. 3GPP Network Exposure Function is a good example for network information exposure, but it is part of 5G core which enables data exchange between UE and application server and does not extend to other domain. 2. ZSM multi-domain network and service management can be another concrete example for multiple domain network information exposure which can be used to have a quick response to network anomaly or reroute the traffic to the less congested path [https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf]. 3. PCE has similar design for multi-domain setting, which allows PCE to PCE communication. Thank you again for the pointers. I'll take a look at ZSM and PCE soon. Best Qiao -Qin 发件人: Qiao Xiang [mailto:xiang...@gmail.com<mailto:xiang...@gmail.com>] 发送时间: 2021年3月3日 0:18 收件人: 刘鹏 mailto:liupeng...@chinamobile.com>> 抄送: Y. Richard Yang mailto:y...@cs.yale.edu>>; IETF ALTO mailto:alto@i
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 triangle routing) and complex on the client side (client must handle data consistency to support dynamic subscribers). I think the generic framework should contain two aspects: [KAI] 1. Control of ALTO information: a server-client protocol which is similar to RFC 8895 but maybe with some extended capabilities. [KAI] 2. Distribution of ALTO information: a MQ-like protocol that controls how the ALTO information can be efficiently and consistently delivered to subscribers. [KAI] I think the connection between these two aspects is a logical entity called ALTO Exchange (following the term used by rabbitMQ). This entity ca
Re: [alto] ALTO Draft ReCharter WG review
t; think >> >> 1. 3GPP Network Exposure Function is a good example for network >> information exposure, but it is part of 5G core which enables data exchange >> between UE and application server and does not extend to other domain. >> >> 2. ZSM multi-domain network and service management can be another >> concrete example for multiple domain network information exposure which can >> be used to have a quick >> >> response to network anomaly or reroute the traffic to the less congested >> path [ >> https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf >> ]. >> >> 3. PCE has similar design for multi-domain setting, which allows PCE to >> PCE communication. >> >> >> Thank you again for the pointers. I'll take a look at ZSM and PCE soon. > > > Best > Qiao > > >> -Qin >> >> *发件人:* Qiao Xiang [mailto:xiang...@gmail.com] >> *发送时间:* 2021年3月3日 0:18 >> *收件人:* 刘鹏 >> *抄送:* Y. Richard Yang ; IETF ALTO ; Qin >> Wu >> *主题:* Re: [alto] ALTO Draft ReCharter WG review >> >> >> >> Hi Peng, Qin and Richard, >> >> >> >> Very good discussion! Richard and I have been working with folks from CMS >> and ESNet (a large global multi-domain science network) to design network >> information exposure abstractions and mechanisms in multi-domain >> networks, with privacy requirements considered. The basic idea stems from >> the ALTO path-vector extension but goes beyond to take privacy into >> consideration. The following are some pointers. >> >> >> >> [1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain >> Network Resource Discovery", IEEE JSAC, 2019. ( >> https://ieeexplore.ieee.org/abstract/document/8756056) >> [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed >> Data Analytics", ( >> https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/) >> >> >> >> For the pointers above, the privacy requirement considered in this work >> is that the network information of multiple domains should be exposed to >> applications as a complete, unified aggregation, appearing as much as >> possible as from a single (virtual) network. We design a network >> information obfuscation mechanism so that the application is not able to >> associate any network resource bottleneck information to any domain, >> reducing the risk of exposing network vulnerability. >> >> >> >> In addition, we also studied how to control the routing across multiple >> domains to achieve more flexible end-to-end interdomain routing. >> Essentially, we propose a mechanism that allows networks to expose their >> available interdomain routes, just as BGP looking glasses, so that >> applications can control them. In this setting, we consider the privacy >> setting where each network's BGP export policies are private, and design >> interesting algorithms for applications to select the best policy-compliant >> routes without knowing the export policies. The following is the pointer >> for this study: >> >> >> >> [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 ( >> https://ieeexplore.ieee.org/abstract/document/9155486) >> >> >> >> Above are our current efforts on extending ALTO to multi-domain settings. >> It would be great if we can know more about the industry efforts on network >> information exposure in multi-domain settings, and the privacy requirements >> of operators. This would be extremely helpful to push this extension >> forward! :-) >> >> >> >> >> >> >> >> Best >> >> Qiao >> >> >> >> On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 wrote: >> >> Hi Richard, >> >> >> >> Thank you. please see my reply inline below. >> >> >> >> >> >> Peng Liu | 刘鹏 >> >> China Mobile | 移动研究院 >> >> mobile phone：13810146105 >> >> email: * liupeng...@chinamobile.com * >> >> >> >> 发件人: Y. Richard Yang >> >> 时间: 2021/03/02(星期二)07:36 >> >> 收件人: 刘鹏 ; >> >> 抄送人: IETF ALTO ;Qin Wu ; >> >> 主题: Re: [alto] ALTO Draft ReCharter WG review >> >> Dear Peng, >> >> >> >> Thank you so much for the feedback. Please see below. >> >> >> >> On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 wrote: >> >> Hi WG, >> >> >> >> Here are some consi
Re: [alto] ALTO Draft ReCharter WG review -- ALTO Data Model
Hi Jensen, >> Yes the YANG needs to follow whatever decision is taken regarding the >> ALTO server-to-server communication. There is also a high-level >> decision that if we have a single YANG model for ALTO that can be used >> by both client and server or have independent yang models: one for >> client and another for server. >> > > My personal feeling is that the configuration requirements for the ALTO > server and client are very different. e.g., The ALTO server needs to be > configured which services it can provide, while the ALTO client needs to be > configured which servers and services it would like to request. So I'm not > sure if we should define a single YANG model for both client and server. > But I notice that PCEP defines a single model for both PCE and PCC. From > your experience, which decision is better for ALTO? > > Dhruv: To me, this would be dependent on what we do with ALTO server-to-server communication. If one server is acting as a client and would need management in the same way as a stand-alone ALTO client, then a single model helps avoid duplication. >> Using the YANG model for monitoring purposes (status, error, >> statistics) at the ALTO client/server is quite useful. >> > > Thanks for your suggestion. From your experience, which kind of > information should not be monitored using the YANG model? For example, if > the client wants to record all the historical requests, should we use the > YANG model to do it? Or we should only use the YANG model to track the > immediate status? > > Dhruv: I doubt the ALTO client remembers the past request. YANG cant model data that doesn't exist. Correct me if I am mistaken. The immediate status, the statistics, the last error, is what you would usually find! Thanks! Dhruv Thanks, > Jensen > > >> >> Thanks, >> Dhruv >> >> > It would be great if people can share further comments or their own >> interesting use cases. >> > >> > [1] https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15 >> > [2] >> https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06 >> > >> > Best regards, >> > Jensen >> > >> > >> > On Mon, Feb 22, 2021 at 9:51 PM Qin Wu wrote: >> >> >> >> 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
Re: [alto] ALTO Draft ReCharter WG review
Sorry, I missed one comment: Qin: I believe your case require server to server communication for end-to-end interdomain routing. My comment: I think we used BGP to provide the e2e interdomain routing information. Best Qiao On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang wrote: > Hi Qin, > > Thank you so much for the feedback. Please see my responses inline. > > On Thu, Mar 4, 2021 at 9:22 PM Qin Wu wrote: > >> Thanks Qiao for sharing your project on Unicorn and thought on >> multi-domain setting. >> >> My impression in your implementation is each domain name and first >> ingress node in such domain will be carried in the ALTO response message. >> > First, for domain name, I do not believe we need that in the ALTO response > message. Our setting here is each domain has an ALTO server, and the ALTO > clients at the aggregator have separate connections to different ALTO > servers. In this way, by maintaining a (domain, ALTO server) mapping, the > aggregator can differentiate responses from different domains. Second, for > ingress node, the client needs to specify the ingress and the (srcIP, > dstIP) pair in the query first so that the ALTO server knows what > information to return. And I should also clarify that although we use > ODL-ALTO for our system, but the path vector extension is not implemented > exactly following the specification since it was not fully stabilized then. > > @Jensen is the core developer and can comment further on this, as well as > the ODL implementation. > > >> One thing I want to highlight is >> >> Unicorn has already been deployed in several cities of USA in 2018 and >> implemented in the ODL open source. >> > I should clarify that this deployment is pre-production, and the > demonstration scenario is at SC18 and SC19, where we are at the conference > cities (Dallas and Denver), and orchestrate traffic from there back to a > Caltech LHC site (we manually separate this site into two domains to create > a 3-domain scenario for demonstration purpose.) > > >> Quote from >> https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/ >> >> “ >> >>The authors build an ALTO server on top of the OpenDaylight Software >> >>Defined Network controller. The ALTO server collects the network >> >>state information from the OpenDaylight controller, e.g., topology, >> >>policy and traffic statistics, processes the collected information >> >>into resource abstraction, and sends the abstraction back to the ALTO >> >>client at the resource orchestrator. >> >> >> >> The Unicorn framework has been deployed and >> >>demonstrated in small federation networks connecting Dallas, Texas, >> >>Los Angles, California, and Denver, Colorado at different >> >>conventions. For example, in 2018, the federation in the >> >>demonstration is composed of three member networks. Network 1 is in >> >>Dallas, Texas, and Network 2 and network 3 are in Los Angeles, >> >>California. Network 1 is connected to network 2 through a layer-2 >> >>WAN circuit with a 100 Gbps bandwidth, provisioned by several >> >>providers such as SCinet, CenturyLink and CENIC. Network 1 is a >> >>temporal science network in the CMS experiment, while network 2 and 3 >> >>are long-running CMS Tier-2 sites. >> >> ” >> >> I believe your case require server to server communication for end-to-end >> interdomain routing. >> >> >> >> Secondly, as for network information exposure in multi-domain setting, I >> think >> >> 1. 3GPP Network Exposure Function is a good example for network >> information exposure, but it is part of 5G core which enables data exchange >> between UE and application server and does not extend to other domain. >> >> 2. ZSM multi-domain network and service management can be another >> concrete example for multiple domain network information exposure which can >> be used to have a quick >> >> response to network anomaly or reroute the traffic to the less congested >> path [ >> https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf >> ]. >> >> 3. PCE has similar design for multi-domain setting, which allows PCE to >> PCE communication. >> >> >> Thank you again for the pointers. I'll take a look at ZSM and PCE soon. > > > Best > Qiao > > >> -Qin >> >> *发件人:* Qiao Xiang [mailto:xiang...@gmail.com] >> *发送时间:* 2021年3月3日 0:18
Re: [alto] ALTO Draft ReCharter WG review
Hi Qin, Thank you so much for the feedback. Please see my responses inline. On Thu, Mar 4, 2021 at 9:22 PM Qin Wu wrote: > Thanks Qiao for sharing your project on Unicorn and thought on > multi-domain setting. > > My impression in your implementation is each domain name and first ingress > node in such domain will be carried in the ALTO response message. > First, for domain name, I do not believe we need that in the ALTO response message. Our setting here is each domain has an ALTO server, and the ALTO clients at the aggregator have separate connections to different ALTO servers. In this way, by maintaining a (domain, ALTO server) mapping, the aggregator can differentiate responses from different domains. Second, for ingress node, the client needs to specify the ingress and the (srcIP, dstIP) pair in the query first so that the ALTO server knows what information to return. And I should also clarify that although we use ODL-ALTO for our system, but the path vector extension is not implemented exactly following the specification since it was not fully stabilized then. @Jensen is the core developer and can comment further on this, as well as the ODL implementation. > One thing I want to highlight is > > Unicorn has already been deployed in several cities of USA in 2018 and > implemented in the ODL open source. > I should clarify that this deployment is pre-production, and the demonstration scenario is at SC18 and SC19, where we are at the conference cities (Dallas and Denver), and orchestrate traffic from there back to a Caltech LHC site (we manually separate this site into two domains to create a 3-domain scenario for demonstration purpose.) > Quote from > https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/ > > “ > >The authors build an ALTO server on top of the OpenDaylight Software > >Defined Network controller. The ALTO server collects the network > >state information from the OpenDaylight controller, e.g., topology, > >policy and traffic statistics, processes the collected information > >into resource abstraction, and sends the abstraction back to the ALTO > >client at the resource orchestrator. > > > > The Unicorn framework has been deployed and > >demonstrated in small federation networks connecting Dallas, Texas, > >Los Angles, California, and Denver, Colorado at different > >conventions. For example, in 2018, the federation in the > >demonstration is composed of three member networks. Network 1 is in > >Dallas, Texas, and Network 2 and network 3 are in Los Angeles, > >California. Network 1 is connected to network 2 through a layer-2 > >WAN circuit with a 100 Gbps bandwidth, provisioned by several > >providers such as SCinet, CenturyLink and CENIC. Network 1 is a > >temporal science network in the CMS experiment, while network 2 and 3 > >are long-running CMS Tier-2 sites. > > ” > > I believe your case require server to server communication for end-to-end > interdomain routing. > > > > Secondly, as for network information exposure in multi-domain setting, I > think > > 1. 3GPP Network Exposure Function is a good example for network > information exposure, but it is part of 5G core which enables data exchange > between UE and application server and does not extend to other domain. > > 2. ZSM multi-domain network and service management can be another concrete > example for multiple domain network information exposure which can be used > to have a quick > > response to network anomaly or reroute the traffic to the less congested > path [ > https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf > ]. > > 3. PCE has similar design for multi-domain setting, which allows PCE to > PCE communication. > > > Thank you again for the pointers. I'll take a look at ZSM and PCE soon. Best Qiao > -Qin > > *发件人:* Qiao Xiang [mailto:xiang...@gmail.com] > *发送时间:* 2021年3月3日 0:18 > *收件人:* 刘鹏 > *抄送:* Y. Richard Yang ; IETF ALTO ; Qin > Wu > *主题:* Re: [alto] ALTO Draft ReCharter WG review > > > > Hi Peng, Qin and Richard, > > > > Very good discussion! Richard and I have been working with folks from CMS > and ESNet (a large global multi-domain science network) to design network > information exposure abstractions and mechanisms in multi-domain > networks, with privacy requirements considered. The basic idea stems from > the ALTO path-vector extension but goes beyond to take privacy into > consideration. The following are some pointers. > > > > [1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain > Network Resource Discovery", IEEE JSAC, 2019. ( &
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? I think this requirement may help integrating ALTO in network management platforms (such as OpenDaylight, Kubernetes, and ETSI ZSM*) which design their own pub-sub systems for reasons such as consistency or ease of development. It would be great if there is an interest in this direction from companies/organizations. [Qin]: I can see The 3GPP has defined a Service-Based Architecture (SBA), whereby the control plane functionality and common data repositories of a 5G network are delivered by way of a set of interconnected Network Functions (NFs),pub sub mechanism has been well adopted in 3GPP interface. Also in the public cloud, popular pub/sub implementations has been widely deployed,e.g., rabbitMQ (AMQP), mosquitto (MQTT), ejabberd (XMPP), and ZeroMQ. We also see many pub sub mechanism or extension has been developed in IETF, e.g., YANG Push, draft-ietf-dots-telemetry, draft-ietf-ace-mqtt-tls-profile. * The integration fabric of ETSI ZSM provides pub-sub support but ZSM also allows services to use their own pub-sub mechanisms. 2. Enable more fine-grained control of pub-sub. In RFC 8895, there are two types of commands which only defines WHAT information to subscribe: - add: Make one or more new requests to receive the incremental updates. - remove: Terminate the subscription of one or more previously-made requests. In the meantime, the updates will be continuously sent to the client whenever a server sees fit. The charter text proposes to enable ALTO clients to request and receive "a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information". It seems to me that the new extension wants to allow clients to specify not only WHAT information to be subscribed but also WHEN/HOW the information should be delivered (e.g., Notify me the latest value every 5 second.). [Qin]:Good point, I think fine grained control of pub-sub allows not only periodical subscription, but also on demand subscription, which is the missing piece in the existing SSE incremental update. Personally I find both directions to be interesting and useful. It would be great if they can be supported by real use cases. Just my two cents. Best, Kai -Original Messages- From:"Qin Wu" mailto:bill...@huawei.com>> Sent Time:2021-02-22 21:50:44 (Monday) To: "IETF ALTO" mailto:alto@ietf.org>> Cc: "alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>" mailto:alto-cha...@ietf.org>>, "alto-...@ietf.org<mailto: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
Re: [alto] ALTO Draft ReCharter WG review
Hi, Wei: Thanks for sharing your SD-WAN use case, very good use case, I think. This case reminds me the LOOP (Local Optimizations on Path Segments) effort in the IETF, which is very similar to CDNI use case, if my understanding is correct, We can query from SD-WAN Edge peer for its capability and footprint. To support redirect traffic to the right network node (e.g., Payment gateway) and when SDWAN edge is partitioned into multiple instances, SDWAN instance ID need to be returned. -Qin 发件人: Wei Wang [mailto:weiwan...@foxmail.com] 发送时间: 2021年3月4日 13:57 收件人: xiangq27 抄送: liupengyjy ; alto ; Qin Wu 主题: Re: [alto] ALTO Draft ReCharter WG review Hi all, I think SD-WAN can be covered by ALTO rechartered work item. SD-WAN can connects the user to any application wherever it resides from the data center to the cloud, and assesses the best path meeting the ideal performance needs for a specific application. SD-WAN can also be used for cross domain scenario. For example, in some cloud-based WAN communications, stitching multiple overlay tunnels in each domain are used for traffic policy enforcement matters such as optimizing traffic distribution or to select the best SD-WAN Edge for best user experience. A SD-WAN Edge can be partitioned into multiple instance, for some instance which can redirect traffic to the payment GW to offer better quality of service. ALTO protocol can be the best option for SD-WAN Edge selection. Best Regards, Wei China Telecom 发件人: Qiao Xiang [mailto:xiang...@gmail.com] 发送时间: 2021年3月3日 0:18 收件人: 刘鹏 mailto:liupeng...@chinamobile.com>> 抄送: Y. Richard Yang mailto:y...@cs.yale.edu>>; IETF ALTO mailto:alto@ietf.org>>; Qin Wu mailto:bill...@huawei.com>> 主题: Re: [alto] ALTO Draft ReCharter WG review Hi Peng, Qin and Richard, Very good discussion! Richard and I have been working with folks from CMS and ESNet (a large global multi-domain science network) to design network information exposure abstractions and mechanisms in multi-domain networks, with privacy requirements considered. The basic idea stems from the ALTO path-vector extension but goes beyond to take privacy into consideration. The following are some pointers. [1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery", IEEE JSAC, 2019. (https://ieeexplore.ieee.org/abstract/document/8756056) [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", (https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/) For the pointers above, the privacy requirement considered in this work is that the network information of multiple domains should be exposed to applications as a complete, unified aggregation, appearing as much as possible as from a single (virtual) network. We design a network information obfuscation mechanism so that the application is not able to associate any network resource bottleneck information to any domain, reducing the risk of exposing network vulnerability. In addition, we also studied how to control the routing across multiple domains to achieve more flexible end-to-end interdomain routing. Essentially, we propose a mechanism that allows networks to expose their available interdomain routes, just as BGP looking glasses, so that applications can control them. In this setting, we consider the privacy setting where each network's BGP export policies are private, and design interesting algorithms for applications to select the best policy-compliant routes without knowing the export policies. The following is the pointer for this study: [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 (https://ieeexplore.ieee.org/abstract/document/9155486) Above are our current efforts on extending ALTO to multi-domain settings. It would be great if we can know more about the industry efforts on network information exposure in multi-domain settings, and the privacy requirements of operators. This would be extremely helpful to push this extension forward! :-) Best Qiao On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 mailto:liupeng...@chinamobile.com>> wrote: Hi Richard, Thank you. please see my reply inline below. Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com<mailto:liupeng...@chinamobile.com> 发件人: Y. Richard Yang<mailto:y...@cs.yale.edu> 时间: 2021/03/02(星期二)07:36 收件人: 刘鹏<mailto:liupeng...@chinamobile.com>; 抄送人: IETF ALTO<mailto:alto@ietf.org>;Qin Wu<mailto:bill...@huawei.com>; 主题: Re: [alto] ALTO Draft ReCharter WG review Dear Peng, Thank you so much for the feedback. Please see below. On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 mailto:liupeng...@chinamobile.com>> wrote: Hi WG, Here are some considerations of recharter: I believe that the multi domain problem is worthy of attention. It is good info. At present, operato
Re: [alto] ALTO Draft ReCharter WG review
Thanks Qiao for sharing your project on Unicorn and thought on multi-domain setting. My impression in your implementation is each domain name and first ingress node in such domain will be carried in the ALTO response message. One thing I want to highlight is Unicorn has already been deployed in several cities of USA in 2018 and implemented in the ODL open source. Quote from https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/ “ The authors build an ALTO server on top of the OpenDaylight Software Defined Network controller. The ALTO server collects the network state information from the OpenDaylight controller, e.g., topology, policy and traffic statistics, processes the collected information into resource abstraction, and sends the abstraction back to the ALTO client at the resource orchestrator. The Unicorn framework has been deployed and demonstrated in small federation networks connecting Dallas, Texas, Los Angles, California, and Denver, Colorado at different conventions. For example, in 2018, the federation in the demonstration is composed of three member networks. Network 1 is in Dallas, Texas, and Network 2 and network 3 are in Los Angeles, California. Network 1 is connected to network 2 through a layer-2 WAN circuit with a 100 Gbps bandwidth, provisioned by several providers such as SCinet, CenturyLink and CENIC. Network 1 is a temporal science network in the CMS experiment, while network 2 and 3 are long-running CMS Tier-2 sites. ” I believe your case require server to server communication for end-to-end interdomain routing. Secondly, as for network information exposure in multi-domain setting, I think 1. 3GPP Network Exposure Function is a good example for network information exposure, but it is part of 5G core which enables data exchange between UE and application server and does not extend to other domain. 2. ZSM multi-domain network and service management can be another concrete example for multiple domain network information exposure which can be used to have a quick response to network anomaly or reroute the traffic to the less congested path [https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf]. 3. PCE has similar design for multi-domain setting, which allows PCE to PCE communication. -Qin 发件人: Qiao Xiang [mailto:xiang...@gmail.com] 发送时间: 2021年3月3日 0:18 收件人: 刘鹏 抄送: Y. Richard Yang ; IETF ALTO ; Qin Wu 主题: Re: [alto] ALTO Draft ReCharter WG review Hi Peng, Qin and Richard, Very good discussion! Richard and I have been working with folks from CMS and ESNet (a large global multi-domain science network) to design network information exposure abstractions and mechanisms in multi-domain networks, with privacy requirements considered. The basic idea stems from the ALTO path-vector extension but goes beyond to take privacy into consideration. The following are some pointers. [1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery", IEEE JSAC, 2019. (https://ieeexplore.ieee.org/abstract/document/8756056) [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", (https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/) For the pointers above, the privacy requirement considered in this work is that the network information of multiple domains should be exposed to applications as a complete, unified aggregation, appearing as much as possible as from a single (virtual) network. We design a network information obfuscation mechanism so that the application is not able to associate any network resource bottleneck information to any domain, reducing the risk of exposing network vulnerability. In addition, we also studied how to control the routing across multiple domains to achieve more flexible end-to-end interdomain routing. Essentially, we propose a mechanism that allows networks to expose their available interdomain routes, just as BGP looking glasses, so that applications can control them. In this setting, we consider the privacy setting where each network's BGP export policies are private, and design interesting algorithms for applications to select the best policy-compliant routes without knowing the export policies. The following is the pointer for this study: [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 (https://ieeexplore.ieee.org/abstract/document/9155486) Above are our current efforts on extending ALTO to multi-domain settings. It would be great if we can know more about the industry efforts on network information exposure in multi-domain settings, and the privacy requirements of operators. This would be extremely helpful to push this extension forward! :-) Best Qiao On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 mailto:liupeng...@chinamobile.com>> wrote: Hi Richard, Thank you. please see my reply
Re: [alto] ALTO Draft ReCharter WG review -- ALTO Data Model
Hi Dhruv, Thanks a lot for your feedback. On Thu, Mar 4, 2021 at 2:07 PM Dhruv Dhody wrote: > Hi Jensen, > > Thanks for starting this thread. It is great that you are thinking of > similar questions as I was :) > > On Wed, Mar 3, 2021 at 9:03 PM Jensen Zhang > wrote: > > > > Dear all, > > > > I would like to make some comments on the 3rd recharter item. > > > > This item is going to propose YANG data models for ALTO configuration > and management. Most of this kind of YANG data models for communication > protocols like PCEP [1] and HTTP [2] will support both client and server > configuration. One of the open issues for ALTO is: > > > > whether we should also provide the data model for the ALTO client > configuration. > > > > If the ALTO client is a function that can be placed in an entity that > uses YANG-based techniques for configuration, status check, and > monitoring. It makes sense for us to provide support for ALTO-client > in YANG model. Some of the use-cases you are already highlighting > below. For some like P2P tracker not soo much! > Thanks for your help to clarify the requirement on when we need the YANG model. > > > For some of the traditional ALTO use cases like p2p, I think the YANG > data model only for the ALTO server is enough. It can help the network > operator easily configure and manage ALTO services. The data model for the > ALTO client may not be necessary because the client is usually not under > the control of the network operator. However, there are two cases where > people may be interested in the data model for the ALTO client: > > > > 1. The multi-domain setting is a potential use case. But it depends on > how we are going to design the server-to-server communication. > > > > (a) If we are going to reuse the current ALTO framework, then the > architecture could be similar to the PCE-based architecture, i.e., each > ALTO domain should initiate an entity that can be an alto-server, > alto-client, or alto-server-and-client. And for the alto-client or > alto-server-and-client entity, the operator could configure the list of > peered alto-server/alto-server-and-client entity directly, or how to > discover the peers. The operator could also configure which information the > client entity is interested in and would like to fetch from the peers. > > > > (b) If we are going to completely redesign the communication protocol > among ALTO servers, we may need specific data models for the configuration > of this new protocol. The traditional roles of the ALTO client and server > may no longer be applicable. > > > > Yes the YANG needs to follow whatever decision is taken regarding the > ALTO server-to-server communication. There is also a high-level > decision that if we have a single YANG model for ALTO that can be used > by both client and server or have independent yang models: one for > client and another for server. > My personal feeling is that the configuration requirements for the ALTO server and client are very different. e.g., The ALTO server needs to be configured which services it can provide, while the ALTO client needs to be configured which servers and services it would like to request. So I'm not sure if we should define a single YANG model for both client and server. But I notice that PCEP defines a single model for both PCE and PCC. From your experience, which decision is better for ALTO? > > BTW RFC 7971 includes this - > >Cascaded servers: An ALTO server may itself include an ALTO >client and query other ALTO servers, e.g., for certain >destinations. This results is a cascaded deployment of ALTO >servers, as further explained below. > > Yes, this is a simple or special case of the multi-domain setting. In this case, the ALTO server can use the legacy ALTO protocol to communicate with other ALTO servers. But there are some limitations in more practical settings. So the 4th recharter item is proposed to try to address them. > > > 2. The other use case could come from the network-application > integration. More specifically, the multi-service operator (e.g., Comcast, > Telefonica) who can offer both application service (e.g., TV, CDN) and > network service can be an example. In such a case, the application service > operator may have some collaboration with the network operator on the > protocol configuration level. > > > > For example, in a CDN-ISP collaboration setting (@Luis can comment on > it), the CDN operator may request the network operator to install a new > ALTO service to compute on-demand ALTO information resources based on new > parameters dynamically. And in the meantime, the CDN operator may also > configure its own ALTO client to periodically send requests to the new ALTO > service or use the pub/sub mechanism (e.g. SSE). And the CDN operator may > want the ALTO client to report some operational status/statistics like when > the last request is done, whether the last response is out-dated, how many >
Re: [alto] ALTO Draft ReCharter WG review -- ALTO Data Model
Hi Jensen, Thanks for starting this thread. It is great that you are thinking of similar questions as I was :) On Wed, Mar 3, 2021 at 9:03 PM Jensen Zhang wrote: > > Dear all, > > I would like to make some comments on the 3rd recharter item. > > This item is going to propose YANG data models for ALTO configuration and > management. Most of this kind of YANG data models for communication protocols > like PCEP [1] and HTTP [2] will support both client and server configuration. > One of the open issues for ALTO is: > > whether we should also provide the data model for the ALTO client > configuration. > If the ALTO client is a function that can be placed in an entity that uses YANG-based techniques for configuration, status check, and monitoring. It makes sense for us to provide support for ALTO-client in YANG model. Some of the use-cases you are already highlighting below. For some like P2P tracker not soo much! > For some of the traditional ALTO use cases like p2p, I think the YANG data > model only for the ALTO server is enough. It can help the network operator > easily configure and manage ALTO services. The data model for the ALTO client > may not be necessary because the client is usually not under the control of > the network operator. However, there are two cases where people may be > interested in the data model for the ALTO client: > > 1. The multi-domain setting is a potential use case. But it depends on how we > are going to design the server-to-server communication. > > (a) If we are going to reuse the current ALTO framework, then the > architecture could be similar to the PCE-based architecture, i.e., each ALTO > domain should initiate an entity that can be an alto-server, alto-client, or > alto-server-and-client. And for the alto-client or alto-server-and-client > entity, the operator could configure the list of peered > alto-server/alto-server-and-client entity directly, or how to discover the > peers. The operator could also configure which information the client entity > is interested in and would like to fetch from the peers. > > (b) If we are going to completely redesign the communication protocol among > ALTO servers, we may need specific data models for the configuration of this > new protocol. The traditional roles of the ALTO client and server may no > longer be applicable. > Yes the YANG needs to follow whatever decision is taken regarding the ALTO server-to-server communication. There is also a high-level decision that if we have a single YANG model for ALTO that can be used by both client and server or have independent yang models: one for client and another for server. BTW RFC 7971 includes this - Cascaded servers: An ALTO server may itself include an ALTO client and query other ALTO servers, e.g., for certain destinations. This results is a cascaded deployment of ALTO servers, as further explained below. > 2. The other use case could come from the network-application integration. > More specifically, the multi-service operator (e.g., Comcast, Telefonica) who > can offer both application service (e.g., TV, CDN) and network service can be > an example. In such a case, the application service operator may have some > collaboration with the network operator on the protocol configuration level. > > For example, in a CDN-ISP collaboration setting (@Luis can comment on it), > the CDN operator may request the network operator to install a new ALTO > service to compute on-demand ALTO information resources based on new > parameters dynamically. And in the meantime, the CDN operator may also > configure its own ALTO client to periodically send requests to the new ALTO > service or use the pub/sub mechanism (e.g. SSE). And the CDN operator may > want the ALTO client to report some operational status/statistics like when > the last request is done, whether the last response is out-dated, how many > versions are updated for the current information resource (Not quite sure if > this info should be in the scope of the ALTO data model). It makes more sense > to do these kinds of things via the configuration protocol instead of another > ALTO protocol extension. > Using the YANG model for monitoring purposes (status, error, statistics) at the ALTO client/server is quite useful. Thanks, Dhruv > It would be great if people can share further comments or their own > interesting use cases. > > [1] https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15 > [2] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06 > > Best regards, > Jensen > > > On Mon, Feb 22, 2021 at 9:51 PM Qin Wu wrote: >> >> 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
Re: [alto] ALTO Draft ReCharter WG review
Hi all, I think SD-WAN can be covered by ALTO rechartered work item. SD-WAN can connects the user to any application wherever it resides from the data center to the cloud, and assesses the best path meeting the ideal performance needs for a specific application. SD-WAN can also be used for cross domain scenario. For example, in some cloud-based WAN communications, stitching multiple overlay tunnels in each domain are used for traffic policy enforcement matters such as optimizing traffic distribution or to select the best SD-WAN Edge for best user experience. A SD-WAN Edge can be partitioned into multiple instance, for some instance which can redirect traffic to the payment GW to offer better quality of service. ALTO protocol can be the best option for SD-WAN Edge selection. Best Regards, Wei China Telecom ??: Qiao Xiang [mailto:xiang...@gmail.com] : 2021??3??3?? 0:18 ??: https://ieeexplore.ieee.org/abstract/document/8756056) [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", (https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/) For the pointers above, the privacy requirement considered in this work is that the network information of multiple domains should be exposed to applications as a complete, unified aggregation, appearing as much as possible as from a single (virtual) network. We design a network information obfuscation mechanism so that the application is not able to associate any network resource bottleneck information to any domain, reducing the risk of exposing network vulnerability. In addition, we also studied how to control the routing across multiple domains to achieve more flexible end-to-end interdomain routing. Essentially, we propose a mechanism that allows networks to expose their available interdomain routes, just as BGP looking glasses, so that applications can control them. In this setting, we consider the privacy setting where each network's BGP export policies are private, and design interesting algorithms for applications to select the best policy-compliant routes without knowing the export policies. The following is the pointer for this study: [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 (https://ieeexplore.ieee.org/abstract/document/9155486) Above are our current efforts on extending ALTO to multi-domain settings. It would be great if we can know more about the industry efforts on network information exposure in multi-domain settings, and the privacy requirements of operators. This would be extremely helpful to push this extension forward! :-) Best Qiao On Tue, Mar 2, 2021 at 1:14 PM https://www.ietf.org/mailman/listinfo/alto -- -- = | Y. Richard Yang http://www.cs.yale.edu/~yry/| = ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto -- Qiao Xiang Professor, School of Informatics, Xiamen University___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] ALTO Draft ReCharter WG review -- ALTO Data Model
Dear all, I would like to make some comments on the 3rd recharter item. This item is going to propose YANG data models for ALTO configuration and management. Most of this kind of YANG data models for communication protocols like PCEP [1] and HTTP [2] will support both client and server configuration. One of the open issues for ALTO is: *whether we should also provide the data model for the ALTO client configuration*. For some of the traditional ALTO use cases like p2p, I think the YANG data model only for the ALTO server is enough. It can help the network operator easily configure and manage ALTO services. The data model for the ALTO client may not be necessary because the client is usually not under the control of the network operator. However, there are two cases where people may be interested in the data model for the ALTO client: 1. The multi-domain setting is a potential use case. But it depends on how we are going to design the server-to-server communication. (a) If we are going to reuse the current ALTO framework, then the architecture could be similar to the PCE-based architecture, i.e., each ALTO domain should initiate an entity that can be an alto-server, alto-client, or alto-server-and-client. And for the alto-client or alto-server-and-client entity, the operator could configure the list of peered alto-server/alto-server-and-client entity directly, or how to discover the peers. The operator could also configure which information the client entity is interested in and would like to fetch from the peers. (b) If we are going to completely redesign the communication protocol among ALTO servers, we may need specific data models for the configuration of this new protocol. The traditional roles of the ALTO client and server may no longer be applicable. 2. The other use case could come from the network-application integration. More specifically, the multi-service operator (e.g., Comcast, Telefonica) who can offer both application service (e.g., TV, CDN) and network service can be an example. In such a case, the application service operator may have some collaboration with the network operator on the protocol configuration level. For example, in a CDN-ISP collaboration setting (@Luis can comment on it), the CDN operator may request the network operator to install a new ALTO service to compute on-demand ALTO information resources based on new parameters dynamically. And in the meantime, the CDN operator may also configure its own ALTO client to periodically send requests to the new ALTO service or use the pub/sub mechanism (e.g. SSE). And the CDN operator may want the ALTO client to report some operational status/statistics like when the last request is done, whether the last response is out-dated, how many versions are updated for the current information resource (Not quite sure if this info should be in the scope of the ALTO data model). It makes more sense to do these kinds of things via the configuration protocol instead of another ALTO protocol extension. It would be great if people can share further comments or their own interesting use cases. [1] https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15 [2] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06 Best regards, Jensen On Mon, Feb 22, 2021 at 9:51 PM Qin Wu wrote: > 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 >
Re: [alto] ALTO Draft ReCharter WG review
By the way, below are the links to some documents that are mentioned in the previous email. [1] https://tools.ietf.org/html/rfc8895 RFC 8895: Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE) [2] https://tools.ietf.org/html/rfc7540 RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2) [3] https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf ETSI ZSM Architecture (See B.4 and B.5 for pub-sub in ZSM) [4] https://docs.opendaylight.org/projects/controller/en/latest/dev-guide.html#messaging-patterns OpenDaylight MD-SAL [5] https://kubemq.io/ KubeMQ: the native message broker for Kubernetes [2] -Original Messages- From:kai...@scu.edu.cn Sent Time:2021-03-03 21:39:30 (Wednesday) To: "Qin Wu" Cc: "alto-cha...@ietf.org" , "alto-...@ietf.org" , "IETF ALTO" Subject: 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: 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 . I think this requirement may help integrating ALTO in network management platforms (such as OpenDaylight, Kubernetes, and ETSI ZSM*) which design their own pub-sub systems for reasons such as consistency or ease of development. It would be great if there is an interest in this direction from companies/organizations. * The integration fabric of ETSI ZSM provides pub-sub support but ZSM also allows services to use their own pub-sub mechanisms. 2. Enable more fine-grained control of pub-sub. In RFC 8895, there are two types of commands which only defines WHAT information to subscribe: - add: Make one or more new requests to receive the incremental updates. - remove: Terminate the subscription of one or more previously-made requests. In the meantime, the updates will be continuously sent to the client whenever a server sees fit. The charter text proposes to enable ALTO clients to request and receive "a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information". It seems to me that the new extension wants to allow clients to specify not only WHAT information to be subscribed but also WHEN/HOW the information should be delivered (e.g., Notify me the latest value every 5 second.). Personally I find both directions to be interesting and useful. It would be great if they can be supported by real use cases. Just my two cents. Best, Kai -Original Messages- From:"Qin Wu" Sent Time:2021-02-22 21:50:44 (Monday) 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
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: 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 . I think this requirement may help integrating ALTO in network management platforms (such as OpenDaylight, Kubernetes, and ETSI ZSM*) which design their own pub-sub systems for reasons such as consistency or ease of development. It would be great if there is an interest in this direction from companies/organizations. * The integration fabric of ETSI ZSM provides pub-sub support but ZSM also allows services to use their own pub-sub mechanisms. 2. Enable more fine-grained control of pub-sub. In RFC 8895, there are two types of commands which only defines WHAT information to subscribe: - add: Make one or more new requests to receive the incremental updates. - remove: Terminate the subscription of one or more previously-made requests. In the meantime, the updates will be continuously sent to the client whenever a server sees fit. The charter text proposes to enable ALTO clients to request and receive "a diverse types (such as event-triggered/sporadic, continuous), continuous, customized feed of publisher-generated information". It seems to me that the new extension wants to allow clients to specify not only WHAT information to be subscribed but also WHEN/HOW the information should be delivered (e.g., Notify me the latest value every 5 second.). Personally I find both directions to be interesting and useful. It would be great if they can be supported by real use cases. Just my two cents. Best, Kai -Original Messages- From:"Qin Wu" Sent Time:2021-02-22 21:50:44 (Monday) 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
Re: [alto] ALTO Draft ReCharter WG review
Hi, Peng: 发件人: 刘鹏 [mailto:liupeng...@chinamobile.com] 发送时间: 2021年3月2日 11:41 收件人: Qin Wu 抄送: IETF ALTO 主题: Re: RE: [alto] ALTO Draft ReCharter WG review Hi Qin, Thanks you. I still have some questions, please see my reply inline below. Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com<mailto:liupeng...@chinamobile.com> Hi WG, Here are some considerations of recharter: I believe that the multi domain problem is worthy of attention. At present, operators also research in it, which may involve guaranteeing end-to-end network service in the future, such as delay, bandwidth, etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane. [Qin]: thanks for sharing your use case, I think we may have many multi-domain applications. Multiple domain setting is not only referred to multiple administrative domains belonging to the same operator but also referred to cross operator domains. [Peng]: Yes, we can easily find the usecase of cross operators domains such as home broadband. Detnet can be a good use case for muit-domain setting, we may also consider many other use cases such as traffic from source to destination spanning across multiple administrative domain, the computing and storage are distributed in different administrative domain [Peng]: DetNet WG only solves the problem of single domain, because multi domain brings much more challenge to the deterministic latency guarantee. It may be difficult to implement strict multi domain deterministic latency guarantee now, but we may gradually optimize it. [Qin-1]Yes, you are right, reading Detnet charter, its scope did focuses on single administrative control domain or within a closed group of administrative control domain. I believe RAW WG also focuses on single domain issue. Which require resource discovery or multi domain SFC case. As stipulated by RFC7971, there is the network consisting of multiple domains and in many cases it is not possible to collect information across network borders. This issue can be addressed by deploying ALTO server in each domain with hierarchy design or mesh design, and allow server to server communication. In addition, we need to consider multi domain connectivity discovery, multi domain service discovery. [Peng]: I agree that it is difficult 'to collect information across network borders', and can you explain more about the "hierarchy design or mesh design"? For the 'multi domain connectivity discovery, multi domain service discovery', is there any usecase or requirements can be found now? [Qin-1]:In hierarchy design, ALTO servers in the domain partitions (e.g., each local domain) gather local information and send it to centralized ALTO server. The mesh design, is more like peer to peer pattern design, ALTO servers may be set up in each domain independently, and gathering the network information from other connected adjacent domains. Multi-domain connectivity discovery, multi service discovery is the solutions proposed for the corresponding use case. multi-service discovery is more related to ALTO server discovery, I think we may leverage existing mechanism proposed in RFC8686. Multi-connectivity discovery is to expand ALTO path vector mechanism to multi domain setting. Special requirements for multi-domain setting is to carry network information across domain which include domain identifier information, we may also consider to carry compute information, which help combine network information and compute information for service edge discovery. Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion. [Qin]:I think one good use case we have is MOWIE use case, i.e., adjust the bitrate to improve Cloud gaming QoE experience based on abstract network information to be exposed. For this use case, we can see a good collaboration between OTT provider and network operation, Probably they sign agreement for the mutual benefits reason. Also network operator will provide aggregate and abstract network information and expose very few information to the client, this is what ALTO is designed for. The proposed work items related to MOWIE, feel free to review and evaluate it' [Peng]: Thanks. I talked to Gang about MOWIE before. It involves some new cooperation modes, which are worthy of further discussion and exploration in details. [Qin-1]:Besides MOWIE which require collaboration between OTT and network provider, we can also envision that the network provider or MSO deploy some content service or TV servic
Re: [alto] ALTO Draft ReCharter WG review
Hi Peng, Qin and Richard, Very good discussion! Richard and I have been working with folks from CMS and ESNet (a large global multi-domain science network) to design network information exposure abstractions and mechanisms in multi-domain networks, with privacy requirements considered. The basic idea stems from the ALTO path-vector extension but goes beyond to take privacy into consideration. The following are some pointers. [1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery", IEEE JSAC, 2019. ( https://ieeexplore.ieee.org/abstract/document/8756056) [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", ( https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/) For the pointers above, the privacy requirement considered in this work is that the network information of multiple domains should be exposed to applications as a complete, unified aggregation, appearing as much as possible as from a single (virtual) network. We design a network information obfuscation mechanism so that the application is not able to associate any network resource bottleneck information to any domain, reducing the risk of exposing network vulnerability. In addition, we also studied how to control the routing across multiple domains to achieve more flexible end-to-end interdomain routing. Essentially, we propose a mechanism that allows networks to expose their available interdomain routes, just as BGP looking glasses, so that applications can control them. In this setting, we consider the privacy setting where each network's BGP export policies are private, and design interesting algorithms for applications to select the best policy-compliant routes without knowing the export policies. The following is the pointer for this study: [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 ( https://ieeexplore.ieee.org/abstract/document/9155486) Above are our current efforts on extending ALTO to multi-domain settings. It would be great if we can know more about the industry efforts on network information exposure in multi-domain settings, and the privacy requirements of operators. This would be extremely helpful to push this extension forward! :-) Best Qiao On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 wrote: > Hi Richard, > > Thank you. please see my reply inline below. > > > Peng Liu | 刘鹏 > China Mobile | 移动研究院 > mobile phone：13810146105 > email: * liupeng...@chinamobile.com * > > > 发件人: Y. Richard Yang > 时间: 2021/03/02(星期二)07:36 > 收件人: 刘鹏 ; > 抄送人: IETF ALTO ;Qin Wu ; > 主题: Re: [alto] ALTO Draft ReCharter WG review > > Dear Peng, > > Thank you so much for the feedback. Please see below. > > On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 wrote: > >> Hi WG, >> >> >> Here are some considerations of recharter: >> >> I believe that the multi domain problem is worthy of attention. >> > > It is good info. > > >> At present, operators also research in it, which may involve guaranteeing >> end-to-end network service in the future, such as delay, bandwidth, etc. >> There are some researches on cross domain deterministic network in the >> industry, which need some support from management and control plane. >> > > Do you want to share some pointers? > > [Peng] As Qin said, it is hard to collect information across network > borders. > > Just taking deterministic network as an example, it is hard to applying > synchronization, unified forwarding strategy in multi domain, so there > are some works need to be done with management plane. Due to the large > scale and multi domains or operators, the management system may be > distributed. > > A potential way is to consider negotiating the forwarding time of each > domain in advance and carrying time stamp in the message to control the > forwarding path of each domain. While it needs some agreements like > contracts to prevent one party from tampering with and denying the > management content. > > Beside this, there may be others use case. I'm not sure if Alto servers > are willing to do those work, but it may be helpful to collect or configure > some key information. > > Who is the provider of Alto service is related to the deployment and >> cooperation mode. It may be difficult for operators to give too much >> detailed network information now. If the Alto service belongs to the >> operator, it may be used to help manage its own network. If Alto service >> belong to non operators, I think the issue of how to cooperate needs >> further discussion. >> >> >> It looks that you want to consider both modes: multidomains but single > operator (i.e., intra-cooperation) and multidomains and multiple operators. &
Re: [alto] ALTO Draft ReCharter WG review
Hi Qin, Thanks you. I still have some questions, please see my reply inline below. Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com Hi WG, Here are some considerations of recharter: I believe that the multi domain problem is worthy of attention. At present, operators also research in it, which may involve guaranteeing end-to-end network service in the future, such as delay, bandwidth, etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane. [Qin]: thanks for sharing your use case, I think we may have many multi-domain applications. Multiple domain setting is not only referred to multiple administrative domains belonging to the same operator but also referred to cross operator domains. [Peng]: Yes, we can easily find the usecase of cross operators domains such as home broadband. Detnet can be a good use case for muit-domain setting, we may also consider many other use cases such as traffic from source to destination spanning across multiple administrative domain, the computing and storage are distributed in different administrative domain [Peng]: DetNet WG only solves the problem of single domain, because multi domain brings much more challenge to the deterministic latency guarantee. It may be difficult to implement strict multi domain deterministic latency guarantee now, but we may gradually optimize it. Which require resource discovery or multi domain SFC case. As stipulated by RFC7971, there is the network consisting of multiple domains and in many cases it is not possible to collect information across network borders. This issue can be addressed by deploying ALTO server in each domain with hierarchy design or mesh design, and allow server to server communication. In addition, we need to consider multi domain connectivity discovery, multi domain service discovery. [Peng]: I agree that it is difficult 'to collect information across network borders', and can you explain more about the "hierarchy design or mesh design"? For the 'multi domain connectivity discovery, multi domain service discovery', is there any usecase or requirements can be found now? Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion. [Qin]:I think one good use case we have is MOWIE use case, i.e., adjust the bitrate to improve Cloud gaming QoE experience based on abstract network information to be exposed. For this use case, we can see a good collaboration between OTT provider and network operation, Probably they sign agreement for the mutual benefits reason. Also network operator will provide aggregate and abstract network information and expose very few information to the client, this is what ALTO is designed for. The proposed work items related to MOWIE, feel free to review and evaluate it' [Peng]: Thanks. I talked to Gang about MOWIE before. It involves some new cooperation modes, which are worthy of further discussion and exploration in details. 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. ” Thanks! Regards, Peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com 发件人: Qin Wu 时间: 2021/02/22(星期一)21:45 收件人: IETF ALTO; 抄送人: alto-chairs;alto-ads; 主题: [alto] ALTO Draft ReCharter WG review Hi, : We have requested one hour session for ALTO WG mee
Re: [alto] ALTO Draft ReCharter WG review
Dear Peng, Thank you so much for the feedback. Please see below. On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 wrote: > Hi WG, > > > Here are some considerations of recharter: > > I believe that the multi domain problem is worthy of attention. > It is good info. > At present, operators also research in it, which may involve guaranteeing > end-to-end network service in the future, such as delay, bandwidth, etc. > There are some researches on cross domain deterministic network in the > industry, which need some support from management and control plane. > Do you want to share some pointers? Who is the provider of Alto service is related to the deployment and > cooperation mode. It may be difficult for operators to give too much > detailed network information now. If the Alto service belongs to the > operator, it may be used to help manage its own network. If Alto service > belong to non operators, I think the issue of how to cooperate needs > further discussion. > > > It looks that you want to consider both modes: multidomains but single operator (i.e., intra-cooperation) and multidomains and multiple operators. Regardless, I agree that it is important for the work to clarify on the privacy requirements. Richard > Regards, > > Peng > > Peng Liu | 刘鹏 > China Mobile | 移动研究院 > mobile phone：13810146105 > email: * liupeng...@chinamobile.com * > > > 发件人: Qin Wu > 时间: 2021/02/22(星期一)21:45 > 收件人: IETF ALTO ; > 抄送人: alto-chairs ;alto-ads ; > 主题: [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
Re: [alto] ALTO Draft ReCharter WG review
Hi, Peng: Thanks for kicking off the discussion, see my reply inline below. 发件人: 刘鹏 [mailto:liupeng...@chinamobile.com] 发送时间: 2021年2月27日 10:23 收件人: IETF ALTO ; Qin Wu 主题: Re: [alto] ALTO Draft ReCharter WG review Hi WG, Here are some considerations of recharter: I believe that the multi domain problem is worthy of attention. At present, operators also research in it, which may involve guaranteeing end-to-end network service in the future, such as delay, bandwidth, etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane. [Qin]: thanks for sharing your use case, I think we may have many multi-domain applications. Multiple domain setting is not only referred to multiple administrative domains belonging to the same operator but also referred to cross operator domains. Detnet can be a good use case for muit-domain setting, we may also consider many other use cases such as traffic from source to destination spanning across multiple administrative domain, the computing and storage are distributed in different administrative domain Which require resource discovery or multi domain SFC case. As stipulated by RFC7971, there is the network consisting of multiple domains and in many cases it is not possible to collect information across network borders. This issue can be addressed by deploying ALTO server in each domain with hierarchy design or mesh design, and allow server to server communication. In addition, we need to consider multi domain connectivity discovery, multi domain service discovery. Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion. [Qin]:I think one good use case we have is MOWIE use case, i.e., adjust the bitrate to improve Cloud gaming QoE experience based on abstract network information to be exposed. For this use case, we can see a good collaboration between OTT provider and network operation, Probably they sign agreement for the mutual benefits reason. Also network operator will provide aggregate and abstract network information and expose very few information to the client, this is what ALTO is designed for. The proposed work items related to MOWIE, feel free to review and evaluate it “ 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. ” Thanks! Regards, Peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com<mailto:liupeng...@chinamobile.com> 发件人: Qin Wu<mailto:bill...@huawei.com> 时间: 2021/02/22(星期一)21:45 收件人: IETF ALTO<mailto:alto@ietf.org>; 抄送人: alto-chairs<mailto:alto-cha...@ietf.org>;alto-ads<mailto:alto-...@ietf.org>; 主题: [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 devi
Re: [alto] ALTO Draft ReCharter WG review
Normal 07.8 磅 0 2 false false false EN-US ZH-CN X-NONE MicrosoftInternetExplorer4 Hi WG, Here are some considerations of recharter: I believe that the multi domain problem is worthy of attention. At present, operators also research in it, which may involve guaranteeing end-to-end network service in the future, such as delay, bandwidth, etc. There are some researches on cross domain deterministic network in the industry, which need some support from management and control plane. Who is the provider of Alto service is related to the deployment and cooperation mode. It may be difficult for operators to give too much detailed network information now. If the Alto service belongs to the operator, it may be used to help manage its own network. If Alto service belong to non operators, I think the issue of how to cooperate needs further discussion. Regards, Peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com 发件人: Qin Wu 时间: 2021/02/22(星期一)21:45 收件人: IETF ALTO; 抄送人: alto-chairs;alto-ads; 主题: [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
[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 multiple ALTO servers, and (2) extend or introduce ALTO services allowing east-west interfaces for multiple ALTO server integration and collaboration. The specifications and extensions should use existing services whenever possible. The specifications and extensions should consider realistic complexities including incremental deployment, dynamicity, and security issues such as access control, authorization (e.g., an ALTO server provides information for a network that the server has no authorization), and privacy protection in multi-domain settings. o The working group will update RFC 7971 to provide operational considerations for recent protocol extensions (e.g., cost calendar, unified properties, and path vector) and new extensions that the WG develops. New considerations will include decisions about the set of information resources (e.g., what metrics to use), notification of changes either in proactive or reactive mode (e.g., pull the backend, or trigger just-in-time measurements), aggregation/processing of the collected information (e.g., compute information and network information )according to the clients' requests, and integration with new transport mechanisms (e.g., HTTP/2 and HTTP/3). When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility: - Can the ALTO server realistically provide (measure or derive) that information? - Is it information that the ALTO client cannot find easily some other way? - Is the distribution of
