Re: [Teas-ns-dt] Availability

[Greg Mirsky <[e-mail]>]

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
>>>>>
>>>>