Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

["Y. Richard Yang" <[e-mail]>]

Hi Sabine,

Thanks a lot for the paragraph describing a potential recharter item.

I have three quick comments, according to my understanding:

- [C1] The extension will focus on "additional" information such as
conditions/context on entities (e.g., extend unified properties) and path
costs (e.g., extend endpoint cost services, cost map services). I can see
such a capability as an instance of a generic capability to allow more
efficient information distribution; that is, instead of asking the server
each every time, the client is given the condition/policy and the
information, and the client can decide, locally, whether to use the
information (and/or what information is applicable). I see two benefits:
(1) reduce the latency for the client to query (and reduce server load
during congestion), and (2) potentially reduce information (e.g., instead
of A, B, A, B from server to client when the condition/context switches
between two states, the server send A and B and the condition to watch
for). Is this the right way to understand the benefits of the item? If so,
it may help to add sentences on the issues that the item addresses (e.g.,
low efficiency of information distribution)?

- [C2] If the preceding understanding is correct, then maybe the item can
be described using a more specific term, instead of the generic term of
general protocol extension. Also, the condition/context still appears to
help a client to decide "where" and "when" to connect but also under which
conditions, with the "when" being understood in both temporal (time) and
logical senses. Hence, I feel that some clarification of the term can help.

- [C3] Moving from the "problem" (why) part to the "feasibility" (how)
part. How about we constrain the design space some more? For example, one
can envision using the power of the full mathematical logic (simple Boolean
logic, temporal logic, ...) to specify the context/conditions. This can be
powerful but also may be complex to finish in a target time frame of say
only 1-2 years.

Talk to you tomorrow and we can go over some more details to wrap up.

Richard

On Mon, Nov 16, 2020 at 12:35 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[e-mail]> wrote:

> 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) <
> [e-mail]>
> *Sent:* Monday, November 16, 2020 6:16 PM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> [e-mail]>; IETF ALTO <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *Randriamasy, Sabine
> (Nokia - FR/Paris-Saclay)
> *Sent:* Tuesday, November 10, 2020 7:24 PM
> *To:* IETF ALTO <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto