Re: [Teas-ns-dt] Availability

[Greg Mirsky <[e-mail]>]

Hi Jeff,
perhaps you can share how you interpret the definition of the availability
in the current version and, particularly, what is "performance":
      Availability: It a measure of how often a customer defined service
      is lost or degraded to the point of unacceptable performance due
      to any fault in the network.  It is a ratio of time the transport
      slice meets agreed SLO over the total time where the transport
      slice is contracted.
Also, what is the measurement unit of the SLO that is used as the threshold
that separates "meets SLO" from "doesn't meet SLO"?

Regards,
Greg

On Mon, Jun 1, 2020 at 11:59 PM Jeff Tantsura <[e-mail]>
wrote:

> Hi Greg,
>
> No, I disagree, what you are describing is a performance SLA.
> Mixing non comparable objectives within a single objective (that is really
> binary, either TRUE or FALSE) is a bad idea.
>
> Cheers,
> Jeff
> On Jun 1, 2020, 6:14 PM -0700, Greg Mirsky <[e-mail]>om>, wrote:
>
> Hi Jeff,
> that is an interesting quote, thank you. I agree with the relationship
> between SLO and SLA. What I'm not finding - the definition of availability
> (and quality but that is outside the scope of our discussion). Looking once
> again at the current definition:
>       Availability: It a measure of how often a customer defined service
>       is lost or degraded to the point of unacceptable performance due
>       to any fault in the network.  It is a ratio of time the transport
>       slice meets agreed SLO over the total time where the transport
>       slice is contracted.
> The definition refers to the performance. I understand performance as a
> combination of bandwidth, packet loss, and packet latency/jitter. Would you
> agree?
> More, "agreed SLO", in my reading, is "performance", which is a
> compounded. Thus, in my interpretation of the definition, availability is a
> compounded objective. Perhaps we can change the definition.
>
> Regards,
> Greg
>
>
> On Mon, Jun 1, 2020 at 4:16 PM Jeff Tantsura <[e-mail]>
> wrote:
>
>> Copied from wikipedia:
>> "The SLA is the entire agreement that specifies what *service* is to be
>> provided, how it is supported, times, locations, costs, performance, and
>> responsibilities of the parties involved.
>> SLOs are specific measurable characteristics of the SLA such as
>> availability, throughput, frequency, response time, or quality."
>>
>> Compounded SLAs are a common thing, compounded SLOs aren’t, and perhaps
>> we should not use them either.
>>
>> Cheers,
>> Jeff
>> On Jun 1, 2020, 3:18 PM -0700, Greg Mirsky <[e-mail]>om>,
>> wrote:
>>
>> Hi Jeff,
>> many thanks for your patience and clarification. the picture in my head
>> was not the correct one, agreed. But if the Availability is as defined in
>> the current text, it appears to me being dependent on other SLOs, other
>> metrics, e.g., packet loss ratio, packet delay, as well as, path
>> continuity. In other words, the availability does not appear as an
>> independent metric but a composite of other metrics, of other SLOs.
>>
>> Regards,
>> Greg
>>
>>
>>
>> On Mon, Jun 1, 2020 at 3:07 PM Jeff Tantsura <[e-mail]>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> A service (SLA) could have 1 or more SLO’s associated with it.
>>> A SLO is met (TRUE), when its objective is met (within boundaries
>>> specified).
>>> Usually a SLA is composed of a set of SLO’s with logical AND, e.g if any
>>> of SLO’s is FALSE -> SLA (or else)
>>>
>>> Example:
>>> If  SLO (availability) is met but SLO (packet_loss) isn’t, availability
>>> becomes an irrelevant objective.
>>>
>>> Cheers,
>>> Jeff
>>> On Jun 1, 2020, 2:55 PM -0700, Greg Mirsky <[e-mail]>om>,
>>> wrote:
>>>
>>> Hi Jeff,
>>> thank you for the clarification. Does measuring uptime considers whether
>>> all metrics included in SLO are within their respective acceptable limits?
>>> In other words, if the quality of the TS degraded, due to, for example,
>>> excessive packet loss, below the requested threshold, would that time
>>> period be attributed to the Service uptime period? In my experience, uptime
>>> of a node (router, server) is easy to express. Uptime of a service? Much
>>> appreciate it if you help with an example or a reference to the definition.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Mon, Jun 1, 2020 at 2:46 PM Jeff Tantsura <[e-mail]>
>>> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> SLO - is an objective (as the name suggests), not a metric. A metric
>>>> without a context is meaningless.
>>>> SLO makes use of the metrics gathered to derive whether the objective
>>>> has been met.
>>>>
>>>> Example:
>>>> SLO (availability) = uptime 90% over 10 hours
>>>> total_time=10h
>>>> uptime=8h
>>>>
>>>> using the metrics above we can conclude that the total_availability =
>>>> 80%, which is less than the service objective set (90%) ->  SLA(or else)
>>>>
>>>> Hope this clarifies
>>>>
>>>> Cheers,
>>>> Jeff
>>>> On Jun 1, 2020, 2:32 PM -0700, Greg Mirsky <[e-mail]>om>,
>>>> wrote:
>>>>
>>>> Hi Jeff,
>>>> in my reading of the definition, it is the intersection of metrics
>>>> already listed in the SLO. If that is the case, how useful is another
>>>> metric that is only a reflection of other metrics?
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Mon, Jun 1, 2020 at 2:24 PM Jeff Tantsura <[e-mail]>
>>>> wrote:
>>>>
>>>>> Greg,
>>>>>
>>>>> I thought the definition provided was pretty clear and comprehendible,
>>>>> why do we need to rephrase it?
>>>>>
>>>>> Cheers,
>>>>> Jeff
>>>>> On Jun 1, 2020, 2:00 PM -0700, Greg Mirsky <[e-mail]>om>,
>>>>> wrote:
>>>>>
>>>>> Hi Jeff,
>>>>> if we define availability as the ratio of the period all requested in
>>>>> the SLO metrics are within an acceptable range to the time since the
>>>>> service was handed to the customer (I propose to refer to this metric as
>>>>> "availability ratio"), then I think it can be expressed as
>>>>> [image: \bigcap _{i=1}^{n}A_{i}], where Ai is the time period the
>>>>> particular metric remained within its acceptable boundary.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Mon, Jun 1, 2020 at 1:35 PM Jeff Tantsura <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Mostly agree with Eric/Kiran
>>>>>>
>>>>>> It should not be removed, but further clarified.
>>>>>> Network/service availability is a measurable metric, availability =
>>>>>> uptime/total_time(uptime+downtime)
>>>>>> Rule of thumb - a service is deemed available when all the SLO’s
>>>>>> associated with it are met(TRUE).
>>>>>> In a complex/multidimensional service, different objects might have
>>>>>> different availability metrics .
>>>>>> For simplicity sake - total_availability(normalized metric) =
>>>>>> Σ(subservice-1..subservice-n), so both, per SLO as well as composite
>>>>>> metrics can be used.
>>>>>>
>>>>>> Cheers,
>>>>>> Jeff
>>>>>> On Jun 1, 2020, 10:08 AM -0700, Kiran Makhijani <[e-mail]>om>,
>>>>>> wrote:
>>>>>>
>>>>>> Thanks! I support not removing it.
>>>>>>
>>>>>> Sticking with individual SLO seems to be a right decision but can be
>>>>>> deferred to NBI document. we need not state that here.
>>>>>>
>>>>>> -Kiran
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Teas-ns-dt <[e-mail]> *On Behalf Of* Eric
>>>>>> Gray
>>>>>> *Sent:* Monday, June 1, 2020 7:35 AM
>>>>>> *To:* [e-mail]
>>>>>> *Subject:* [Teas-ns-dt] Availability
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree that the definition needs to be cleaned up, but I disagree
>>>>>> that it should be omitted.
>>>>>>
>>>>>>
>>>>>>
>>>>>> A part of what probably should be cleaned up is the part that talks
>>>>>> about service degradation.  In general, this is an important factor in
>>>>>> determining availability, but it is a bit vague for the purpose of
>>>>>> definition.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I also disagree that availability is not measurable.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As a proof of concept for measuring , if there are any mandatory
>>>>>> measurable objectives, then failing to meet any of those objectives makes
>>>>>> the service measurably unavailable.  That is, if you can determine if
>>>>>> specific mandatory objectives are being met, then you can determine if they
>>>>>> are not being met and therefore determine if the service is unavailable.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Availability is an important aspect of any service, because it is
>>>>>> understood that the higher the required availability, the more difficult
>>>>>> (and thus expensive) it is to provide that service.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Defining availability as a fraction as we have done in the draft,
>>>>>> allows for services that may experience a certain amount of outages over a
>>>>>> service period.  A service request may ask for as high an availability as
>>>>>> the provider and requester have agreed to (under the terms they agreed to)
>>>>>> in advance.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that this elevates the importance of having (at least mostly)
>>>>>> measurable objectives, simply because you cannot determine if a
>>>>>> non-measurable objective is being met – hence you cannot (necessarily)
>>>>>> determine the availability of any service that depends on that objective.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It is further interesting to note that the notion of a service
>>>>>> depending on objectives that it cannot determine are not being met is a
>>>>>> non-sequitur.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Measuring availability in terms of mandatory objectives – as a whole
>>>>>> – is the simplest approach; one could group one or more mandatory
>>>>>> objectives and define an availability separately for the group – thus
>>>>>> allowing for a higher degree of acceptance for failing to meet one set of
>>>>>> service objectives compared to others.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If we were going to do that, it would probably be better to define
>>>>>> availability as a parameter that applies individually to service objectives.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In my opinion we should at least initially stick to the simple case,
>>>>>> where availability is defined as a service objective, rather than as a
>>>>>> parameter of every service objective – but I am willing to go either way.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Eric
>>>>>> --
>>>>>> Teas-ns-dt mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>>>>>>
>>>>>> --
>>>>>> Teas-ns-dt mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>>>>>>
>>>>>