Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
Hi Luis, Thanks a lot for your feedback, please see inline Best regards, Sabine From: LUIS MIGUEL CONTRERAS MURILLO Sent: Tuesday, November 17, 2020 11:41 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ; IETF ALTO Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions Hi Sabine, Some few comments, that have been actually mentioned by me during this weekly ALTO regular call. .- I think the General Protocol Extension item for re-charter is a good place holder for maintenance and improvements of current protocol. For instance, I think that aspects such as the use of BGP communities (see draft-contreras-alto-bgp-communities) fits well in some item like this. [ [SR] ] agree, there may be other necessary "general extensions". The proposed item does not mean to be restrictive. .- Regarding the text itself, I do foresee use cases that could apply e.g. indications of SLA characteristics for discriminating the information retrieved. For instance, applications tolerant to the delay (e.g. database backups) could receive different information from those time critical. [ [SR] ] agree, SLA and delay tolerant applications are mentioned in the presentation. Hope this is aligned with your view. Best regards, Luis De: alto mailto:alto-boun...@ietf.org>> En nombre de Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Enviado el: lunes, 16 de noviembre de 2020 18:36 Para: IETF ALTO mailto:alto@ietf.org>> Asunto: Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Hello, Please find below a revision of the proposed definition paragraph. This WG item is further detailed in the Google doc available here (page 19/25): https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit Thanks, Sabine General protocol extensions to convey a richer set of attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged server load in data center supported applications) and to path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>> Sent: Monday, November 16, 2020 6:16 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>>; IETF ALTO mailto:alto@ietf.org>> Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions Dear all, The paragraph below is proposed to define the WG item on "general protocol extensions". As the purpose of this work item is also to support other WG items that may need these extensions, your feedback again is more than welcome. Thanks, Sabine General protocol extensions to convey a richer set of cost attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged (cache storage capacities and) server load in data center supported applications) and to ALTO path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Tuesday, November 10, 2020 7:24 PM To: IETF ALTO mailto:alto@ietf.org>> Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, Please find below a WG item proposal for "general ALTO protocol extensions", on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps
Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
Hi Qin, Thanks a lot for your feedback, The text and slide deck presenting the proposed re-charter item hopefully address your comments. Please see inline. Best regards, Sabine From: Qin Wu Sent: Tuesday, November 17, 2020 4:33 AM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ; IETF ALTO Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions Hi, Sabine: Thanks for the update on the proposed item. See my comments inline. 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 发送时间: 2020年11月17日 1:16 收件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>>; IETF ALTO mailto:alto@ietf.org>> 主题: Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, The paragraph below is proposed to define the WG item on “general protocol extensions”. As the purpose of this work item is also to support other WG items that may need these extensions, your feedback again is more than welcome. Thanks, Sabine General protocol extensions to convey a richer set of cost attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged (cache storage capacities and) server load in data center supported applications) and to ALTO path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Tuesday, November 10, 2020 7:24 PM To: IETF ALTO mailto:alto@ietf.org>> Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, Please find below a WG item proposal for “general ALTO protocol extensions”, on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps to determine when to connect o Extends endpoints to entities on which properties are defined [Qin]:Good, I believe you talk about Path vector, ALTO cost calendar, and unified properties which provide a good basis for any new work. [ [SR] ] indeed -- Basic Issues +++ Issue 1: Some path cost values may depend on "contextual parameters" such as access type, SLA, policy or other indicators provided by network. In particular: - There may be different possible paths between source and destination, where some paths may or may not meet Application QoE or policy constraints. The Applications would like to see which path is most suitable. - Contextual parameters may be available at frequencies that are different from ALTO information frequency. For example, Cost on PID-Cell1 may differ, depending on some real-time network parameter value. [Qin]: I see this contextual parameter as path constraints, besides access type, SLA, policy, I think end to end latency, packet loss can also see as path constraints, which can help select a connection path to meet network performance requirements. [ [SR] ] I think constraints on end to end performance metrics such as latency and packet loss may be better supported with filtering constraints on queries for path costs. “Contextual parameters” are rather used to “detail” cost values wrt the value of a contextual parameter. The expression “Contextual parameters” may be indeed ambiguous and is now named “cost attributes” in the proposed paragraph, to better distinguish with constraints on metrics. Also I think the specific intermediate network elements, transit administrative domain traversed by the flow identified by source destination pair can also be seen as contextual parameter, e.g., we have two end to end paths, we can have contextual parameter like: route the path through transit domain A, route the path not through transit domain B. [ [SR] ] this corresponds to the case where several possible paths are possible. A context parameter Ptd representing transit domains may indeed be used to prevent using a path with prohibitive costs. For instance, Cost(Spid,Dpid) = moderate for Ptd = A and very high for Ptd = B. Such a case should be considered in the
Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
Hi Sabine, Some few comments, that have been actually mentioned by me during this weekly ALTO regular call. .- I think the General Protocol Extension item for re-charter is a good place holder for maintenance and improvements of current protocol. For instance, I think that aspects such as the use of BGP communities (see draft-contreras-alto-bgp-communities) fits well in some item like this. .- Regarding the text itself, I do foresee use cases that could apply e.g. indications of SLA characteristics for discriminating the information retrieved. For instance, applications tolerant to the delay (e.g. database backups) could receive different information from those time critical. Hope this is aligned with your view. Best regards, Luis De: alto En nombre de Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Enviado el: lunes, 16 de noviembre de 2020 18:36 Para: IETF ALTO Asunto: Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Hello, Please find below a revision of the proposed definition paragraph. This WG item is further detailed in the Google doc available here (page 19/25): https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit Thanks, Sabine General protocol extensions to convey a richer set of attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged server load in data center supported applications) and to path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>> Sent: Monday, November 16, 2020 6:16 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>>; IETF ALTO mailto:alto@ietf.org>> Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions Dear all, The paragraph below is proposed to define the WG item on "general protocol extensions". As the purpose of this work item is also to support other WG items that may need these extensions, your feedback again is more than welcome. Thanks, Sabine General protocol extensions to convey a richer set of cost attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged (cache storage capacities and) server load in data center supported applications) and to ALTO path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Tuesday, November 10, 2020 7:24 PM To: IETF ALTO mailto:alto@ietf.org>> Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, Please find below a WG item proposal for "general ALTO protocol extensions", on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps to determine when to connect o Extends endpoints to entities on which properties are defined -- Basic Issues +++ Issue 1: Some path cost values may depend on "contextual parameters" such as access type, SLA, policy or other indicators provided by network. In particular: - There may be different possible paths between source and destination, where some paths may or may not meet Application QoE or policy constraints. The Applications would like to see which path is most suitable. - Contextual parameters may be available at f
Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
Hi, Sabine: Thanks for the update on the proposed item. See my comments inline. 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 发送时间: 2020年11月17日 1:16 收件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ; IETF ALTO 主题: Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, The paragraph below is proposed to define the WG item on “general protocol extensions”. As the purpose of this work item is also to support other WG items that may need these extensions, your feedback again is more than welcome. Thanks, Sabine General protocol extensions to convey a richer set of cost attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged (cache storage capacities and) server load in data center supported applications) and to ALTO path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Tuesday, November 10, 2020 7:24 PM To: IETF ALTO mailto:alto@ietf.org>> Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, Please find below a WG item proposal for “general ALTO protocol extensions”, on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps to determine when to connect o Extends endpoints to entities on which properties are defined [Qin]:Good, I believe you talk about Path vector, ALTO cost calendar, and unified properties which provide a good basis for any new work. -- Basic Issues +++ Issue 1: Some path cost values may depend on "contextual parameters" such as access type, SLA, policy or other indicators provided by network. In particular: - There may be different possible paths between source and destination, where some paths may or may not meet Application QoE or policy constraints. The Applications would like to see which path is most suitable. - Contextual parameters may be available at frequencies that are different from ALTO information frequency. For example, Cost on PID-Cell1 may differ, depending on some real-time network parameter value. [Qin]: I see this contextual parameter as path constraints, besides access type, SLA, policy, I think end to end latency, packet loss can also see as path constraints, which can help select a connection path to meet network performance requirements. Also I think the specific intermediate network elements, transit administrative domain traversed by the flow identified by source destination pair can also be seen as contextual parameter, e.g., we have two end to end paths, we can have contextual parameter like: route the path through transit domain A, route the path not through transit domain B. or if (service_destination matches 10.132.12.0/24) Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1. +++ Issue 2: Some entities may have properties whose values change over time. For instance, ANEs may have time-varying properties on cloud or networking resources [Qin]: ANE having time varying properties on cloud or networking resource, can ANE be set as destination end point, I think we should distinguish whether properties are owned by destination endpoint or intermediate network element? For the former case, we may use for service edge selection in the edge computing case, the properties could be the load, capability. For intermediate network elements, one example property is timestamp or queue length, let me know what is your example properties? -- Potential solution(s) +++ To address issue 1 and related : extend cost attributes towards conditional values and parameters allowing a better interpretation of the received values - Extension from single cost value to array of values dependent on context parameters: allowing applications to make context-dependent decisions, allowing also to combine information generated with different time dynamics, (freshness) See examples on https://datatracker.ietf.org/
Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
IETF working groups that have a focus on > the related use cases. The scope of extensions is not limited to those > identified by the WIs and WGs, but is limited by the criteria set out below. > > > > > > *From:* alto *On Behalf Of *Randriamasy, Sabine > (Nokia - FR/Paris-Saclay) > *Sent:* Tuesday, November 10, 2020 7:24 PM > *To:* IETF ALTO > *Subject:* [alto] ALTO recharter: proposed item - General ALTO protocol > extensions > > > > Dear all, > > > > Please find below a WG item proposal for “general ALTO protocol > extensions”, on which your feedback and suggestions will be more than > welcome. > > Thanks, > > Sabine > > > > -- Context: the current ALTO charter > > o Extends the path cost values in several directions: > > - single to array of several cost metrics => allows apps to > decide upon several metrics and make decision compromise > > - single cost value to array if time dependent cost values > => allow apps to determine when to connect > > o Extends endpoints to entities on which properties are defined > > > > -- Basic Issues > > +++ Issue 1: Some path cost values may depend on "contextual parameters" > such as access type, SLA, policy or other indicators provided by network. > In particular: > > - There may be different possible paths between source and > destination, where some paths may or may not meet Application QoE or policy > constraints. The Applications would like to see which path is most suitable. > > - Contextual parameters may be available at frequencies that > are different from ALTO information frequency. For example, Cost on > PID-Cell1 may differ, depending on some real-time network parameter value. > > > > +++ Issue 2: Some entities may have properties whose values change over > time. For instance, ANEs may have time-varying properties on cloud or > networking resources > > > > -- Potential solution(s) > > +++ To address issue 1 and related : extend cost attributes towards > conditional values and parameters allowing a better interpretation of the > received values > > - Extension from single cost value to array of values dependent on context > parameters: > > allowing applications to make context-dependent decisions, > > allowing also to combine information generated with different time > dynamics, (freshness) > > See examples on > https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/ > > > > +++ To address issue 2: > > - ALTO Property Calendars to extend a single property value to an array of > time-dependent property values > > > > -- Remaining issues to be addressed > > - How to define cost value attributes? > > - How to achieve a light and flexible design? > > - How to moderate additional Server workload and ALTO traffic increase? > > > > -- Who will work on it, rough planning > > +++ Extensions may go in standalone documents and/or extend existing > ones, eg ALTO performance metrics > > +++ Contributors: Sabine and any other interested people > > +++ Plans for IETF 110: > > - Reactivation and update of related existing ALTO drafts > > - First draft for ALTO Property Calendars > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
Hello, Please find below a revision of the proposed definition paragraph. This WG item is further detailed in the Google doc available here (page 19/25): https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit Thanks, Sabine General protocol extensions to convey a richer set of attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged server load in data center supported applications) and to path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Monday, November 16, 2020 6:16 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ; IETF ALTO Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions Dear all, The paragraph below is proposed to define the WG item on "general protocol extensions". As the purpose of this work item is also to support other WG items that may need these extensions, your feedback again is more than welcome. Thanks, Sabine General protocol extensions to convey a richer set of cost attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged (cache storage capacities and) server load in data center supported applications) and to ALTO path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Tuesday, November 10, 2020 7:24 PM To: IETF ALTO mailto:alto@ietf.org>> Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, Please find below a WG item proposal for "general ALTO protocol extensions", on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps to determine when to connect o Extends endpoints to entities on which properties are defined -- Basic Issues +++ Issue 1: Some path cost values may depend on "contextual parameters" such as access type, SLA, policy or other indicators provided by network. In particular: - There may be different possible paths between source and destination, where some paths may or may not meet Application QoE or policy constraints. The Applications would like to see which path is most suitable. - Contextual parameters may be available at frequencies that are different from ALTO information frequency. For example, Cost on PID-Cell1 may differ, depending on some real-time network parameter value. +++ Issue 2: Some entities may have properties whose values change over time. For instance, ANEs may have time-varying properties on cloud or networking resources -- Potential solution(s) +++ To address issue 1 and related : extend cost attributes towards conditional values and parameters allowing a better interpretation of the received values - Extension from single cost value to array of values dependent on context parameters: allowing applications to make context-dependent decisions, allowing also to combine information generated with different time dynamics, (freshness) See examples on https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/ +++ To address issue 2: - ALTO Property Calendars to extend a single property value to an array of time-dependent property values -- Remaining issues to be addressed - How to define cost value attributes? - How to achieve a light and flexible design? - How to modera
Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions
Dear all, The paragraph below is proposed to define the WG item on "general protocol extensions". As the purpose of this work item is also to support other WG items that may need these extensions, your feedback again is more than welcome. Thanks, Sabine General protocol extensions to convey a richer set of cost attributes allowing to determine not only "where" and "when" to connect but also under which conditions. Such additional information will be related both to entities (e.g. conveying time-averaged (cache storage capacities and) server load in data center supported applications) and to ALTO path costs (e.g. ALTO path cost value depending on conditions such as real-time network indications or SLA or policy or access-type or indicator type). The working group will specify such extension in coordination with both other ALTO working group items and IETF working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WIs and WGs, but is limited by the criteria set out below. From: alto On Behalf Of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Sent: Tuesday, November 10, 2020 7:24 PM To: IETF ALTO Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions Dear all, Please find below a WG item proposal for "general ALTO protocol extensions", on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps to determine when to connect o Extends endpoints to entities on which properties are defined -- Basic Issues +++ Issue 1: Some path cost values may depend on "contextual parameters" such as access type, SLA, policy or other indicators provided by network. In particular: - There may be different possible paths between source and destination, where some paths may or may not meet Application QoE or policy constraints. The Applications would like to see which path is most suitable. - Contextual parameters may be available at frequencies that are different from ALTO information frequency. For example, Cost on PID-Cell1 may differ, depending on some real-time network parameter value. +++ Issue 2: Some entities may have properties whose values change over time. For instance, ANEs may have time-varying properties on cloud or networking resources -- Potential solution(s) +++ To address issue 1 and related : extend cost attributes towards conditional values and parameters allowing a better interpretation of the received values - Extension from single cost value to array of values dependent on context parameters: allowing applications to make context-dependent decisions, allowing also to combine information generated with different time dynamics, (freshness) See examples on https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/ +++ To address issue 2: - ALTO Property Calendars to extend a single property value to an array of time-dependent property values -- Remaining issues to be addressed - How to define cost value attributes? - How to achieve a light and flexible design? - How to moderate additional Server workload and ALTO traffic increase? -- Who will work on it, rough planning +++ Extensions may go in standalone documents and/or extend existing ones, eg ALTO performance metrics +++ Contributors: Sabine and any other interested people +++ Plans for IETF 110: - Reactivation and update of related existing ALTO drafts - First draft for ALTO Property Calendars ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] ALTO recharter: proposed item - General ALTO protocol extensions
Dear all, Please find below a WG item proposal for "general ALTO protocol extensions", on which your feedback and suggestions will be more than welcome. Thanks, Sabine -- Context: the current ALTO charter o Extends the path cost values in several directions: - single to array of several cost metrics => allows apps to decide upon several metrics and make decision compromise - single cost value to array if time dependent cost values => allow apps to determine when to connect o Extends endpoints to entities on which properties are defined -- Basic Issues +++ Issue 1: Some path cost values may depend on "contextual parameters" such as access type, SLA, policy or other indicators provided by network. In particular: - There may be different possible paths between source and destination, where some paths may or may not meet Application QoE or policy constraints. The Applications would like to see which path is most suitable. - Contextual parameters may be available at frequencies that are different from ALTO information frequency. For example, Cost on PID-Cell1 may differ, depending on some real-time network parameter value. +++ Issue 2: Some entities may have properties whose values change over time. For instance, ANEs may have time-varying properties on cloud or networking resources -- Potential solution(s) +++ To address issue 1 and related : extend cost attributes towards conditional values and parameters allowing a better interpretation of the received values - Extension from single cost value to array of values dependent on context parameters: allowing applications to make context-dependent decisions, allowing also to combine information generated with different time dynamics, (freshness) See examples on https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/ +++ To address issue 2: - ALTO Property Calendars to extend a single property value to an array of time-dependent property values -- Remaining issues to be addressed - How to define cost value attributes? - How to achieve a light and flexible design? - How to moderate additional Server workload and ALTO traffic increase? -- Who will work on it, rough planning +++ Extensions may go in standalone documents and/or extend existing ones, eg ALTO performance metrics +++ Contributors: Sabine and any other interested people +++ Plans for IETF 110: - Reactivation and update of related existing ALTO drafts - First draft for ALTO Property Calendars ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
