Subject: [Teas-ns-dt] Availability

From: Eric Gray <[email-masked]>
Date: Mon, 1 Jun 2020 14:34:32 +0000

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

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 1 Jun 2020 17:08:00 +0000

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 <[email-masked]> On Behalf Of Eric Gray
Sent: Monday, June 1, 2020 7:35 AM
To: [email-masked]
Subject: [Teas-ns-dt] Availability

--
Eric

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 13:35:12 -0700

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 <[email-masked]>, wrote:
> 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.
>
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 14:00:27 -0700

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
, 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 <[email-masked]>
wrote:

> 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
> 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 <[email-masked]> *On Behalf Of* Eric Gray
> *Sent:* Monday, June 1, 2020 7:35 AM
> *To:* [email-masked]
> *Subject:* [Teas-ns-dt] Availability
>
>
>
> 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.
>
>
>
> 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
> [email-masked]

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 14:23:52 -0700

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 <[email-masked]>, 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
> , 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 <[email-masked]> wrote:

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 14:31:58 -0700

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 <[email-masked]>
wrote:

>> 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
>> [email-masked]

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 14:46:01 -0700

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 <[email-masked]>, 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 <[email-masked]> wrote:
> > > Greg,
> > >

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 14:54:59 -0700

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 <[email-masked]>
wrote:

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

---

From: Eric Gray <[email-masked]>
Date: Mon, 1 Jun 2020 21:56:34 +0000

Greg,

              I agree with Jeff, and would add that this is (again) a definitions draft.  We can iron out a more definite description almost any time after the draft is adopted.

              I practically guarantee that this text will change at least a few times before we are done with last call.

              So, unless we feel that we really need to improve on the part of the definition that talks about the ratio that is used to determine availability before we ask the WG (again) to adopt the draft, we should get there first.

--
Eric

From: Jeff Tantsura <[email-masked]>
Sent: Monday, June 1, 2020 5:24 PM
To: Greg Mirsky <[email-masked]>
Cc: Eric Gray <[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>
Subject: Re: [Teas-ns-dt] Availability

Greg,

I thought the definition provided was pretty clear and [comprehensible], why do we need to rephrase it?

Cheers,
Jeff
On Jun 1, 2020, 2:00 PM -0700, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, 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
[\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 <[email-masked]<mailto:[email-masked]>> wrote:
Mostly agree with Eric/Kiran

Cheers,
Jeff
On Jun 1, 2020, 10:08 AM -0700, Kiran Makhijani <[email-masked]<mailto:[email-masked]>>, wrote:

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Gray
Sent: Monday, June 1, 2020 7:35 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas-ns-dt] Availability

--
Eric
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 15:07:24 -0700

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 <[email-masked]>, 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 <[email-masked]> wrote:
> > > Hi Greg,
> > >

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 15:11:57 -0700

Hi Eric,
sorry to be a pain in the neck but 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
, in my reading, is circular. For example, what is the "unacceptable
performance" to the particular SLO? Is that all metrics being out of
profile at the same time or at least one of the metrics? Further, a fault
is, usually, understood as a defect, loss of path continuity. Is that the
only possible cause of a service degradation? If we understand what is
unacceptable we can easily add it to the definition.

Regards,
Greg

On Mon, Jun 1, 2020 at 2:56 PM Eric Gray <[email-masked]> wrote:

> Greg,
>
>
>
>               I agree with Jeff, and would add that this is (again) a
> definitions draft.  We can iron out a more definite description almost any
> time after the draft is adopted.
>
>
>
>               I practically guarantee that this text will change at least
> a few times before we are done with last call.
>
>
>
>               So, unless we feel that we really need to improve on the
> part of the definition that talks about the ratio that is used to determine
> availability before we ask the WG (again) to adopt the draft, we should get
> there first.
>
>
>
> --
>
> Eric
>
>
>
> *From:* Jeff Tantsura <[email-masked]>
> *Sent:* Monday, June 1, 2020 5:24 PM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* Eric Gray <[email-masked]>; [email-masked]; Kiran
> Makhijani <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] Availability
>
>
>
> Greg,
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 15:18:34 -0700

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 <[email-masked]>
wrote:

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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 16:16:43 -0700

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 <[email-masked]>, 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 <[email-masked]> wrote:
> > > Hi Greg,
> > >

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 18:14:11 -0700

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 <[email-masked]>
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."
>
> 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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 23:59:10 -0700

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 <[email-masked]>, 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:
> 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 <[email-masked]> wrote:
> > > Copied from wikipedia:

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Jun 2020 08:34:51 -0700

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 <[email-masked]>
wrote:

> Mixing non comparable objectives within a single objective (that is really
> binary, either TRUE or FALSE) is a bad idea.
>
> Cheers,
> Jeff
> 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
>
>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>

---

From: Eric Gray <[email-masked]>
Date: Tue, 2 Jun 2020 15:48:14 +0000

Jeff,

              I have to disagree.

              In a simple example, if availability requires a service to be conformant with all SLO parameters at least 99.999 % of the time, then it is possible to have 100% packet loss for the remaining .001 % of the time and still have the service be within SLA.

              To help people to get their heads around this percentage, .001 % of a year is a little over 5 minutes and 15 seconds.

              So, a service may not be meeting any or all of its other SLO parameters and – as long as it is still meeting its availability SLO parameter, it is still within SLA.

              Obviously, under those circumstances, availability does matter.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Monday, June 1, 2020 6:07 PM
To: Greg Mirsky <[email-masked]>
Cc: Kiran Makhijani <[email-masked]>; [email-masked]; Eric Gray <eric.gray=[email-masked]>
Subject: Re: [Teas-ns-dt] Availability

Hi Greg,

Example:

Cheers,
Jeff
On Jun 1, 2020, 2:55 PM -0700, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Jeff,

Regards,
Greg

On Mon, Jun 1, 2020 at 2:46 PM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Example:

Hope this clarifies

Cheers,
Jeff
On Jun 1, 2020, 2:32 PM -0700, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Jeff,

Regards,
Greg

On Mon, Jun 1, 2020 at 2:24 PM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Cheers,
Jeff

Hi Jeff,

Regards,
Greg

Cheers,
Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Jun 2020 09:00:11 -0700

Hi Eric,
it is much better to have a use case to discuss, thank you. Do you think
that availability includes all performance-related parameters, e.g., packet
loss ratio, latency, and jitter? My interpretation of the definition in the
draft is that availability is the intersection of time periods when each
performance-related SLO is within the agreed range. And I think that it is
important to see it as an intersection because if during the same period,
for example, the packet loss ratio is 0% but latency is above its
threshold, that period of time is considered as unavailability period for
the given TS. What do you think?

Regards,
Greg

On Tue, Jun 2, 2020 at 8:48 AM Eric Gray <[email-masked]> wrote:

> Jeff,
>
>
>
>               I have to disagree.
>
>
>
>               In a simple example, if availability requires a service to
> be conformant with all SLO parameters at least 99.999 % of the time, then
> it is possible to have 100% packet loss for the remaining .001 % of the
> time and still have the service be within SLA.
>
>
>
>               To help people to get their heads around this percentage,
> .001 % of a year is a little over 5 minutes and 15 seconds.
>
>
>
>               So, a service may not be meeting any or all of its other SLO
> parameters and – as long as it is still meeting its availability SLO
> parameter, it is still within SLA.
>
>
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of *Jeff
> Tantsura
> *Sent:* Monday, June 1, 2020 6:07 PM
> *Cc:* Kiran Makhijani <[email-masked]>; [email-masked]; Eric
> Gray <eric.gray=[email-masked]>

---

From: Eric Gray <[email-masked]>
Date: Tue, 2 Jun 2020 16:24:46 +0000

Greg,

              As mentioned in a separate thread, it is possible to look at availability as a parameter to be associated with each individual SLO.  I would need to see evidence that it is worth the extra complexity, however, before I would agree that we should do it that way.

              For example, it is conceivable that a service might be defined where the availability is different for packet loss and delay variation.

              There are simpler ways to express this sort of unequal weighting of SLO parameters, however, and my impression (from talking to provider representatives in relevant standards work over multiple decades) is that defining a single availability is the usual case.

              For example, packet loss and availability are both expressed as a percentage, then you can choose a value for packet loss percentage that – in combination with a given availability percentage – results in any desirable SLO loss percentage.

              In other words – if you’re looking to define an SLA that might allow for out-of-bounds delay variation 5 minutes a year, and want to define a packet loss SLO with a consistent availability, you have only to choose an appropriate packet loss percentage (where losing less than the acceptable percentage 99.999 % of a year and then 100% of all packets for 5 minutes is about equal to that percentage).

              As you should see from this example, if the availability is a very high percentage, this sort of math produces a difference that is way down in the statistical “noise” – hence very few people bother dealing with this level of complexity and simply set a single availability for the service.

              Note that another key reason for having a single availability number is that – in the event of a severe service outage (loss, impairment or degradation) – many (if not all) SLO parameters are likely to be out of bounds for approximately the same amount of time.

              Since the case Jeff refers to (where all SLO values are essentially ANDed) is the common case, it is simplest to treat failing to meet any SLO as service unavailability.

              Lastly, in any case where the provider detects the service failure, the way that they will likely have implemented violating their SLA with a subscriber will typically involve switching the service to an alternative – which will likely impact the service’s ability to meet other SLOs.

--
Eric

Hi Greg,

Example:

Cheers,
Jeff

Hi Jeff,

Regards,
Greg

Example:

Hope this clarifies

Cheers,
Jeff

Hi Jeff,

Regards,
Greg

Cheers,
Jeff

Hi Jeff,

Regards,
Greg

Cheers,
Jeff

---

From: Eric Gray <[email-masked]>
Date: Tue, 2 Jun 2020 16:39:14 +0000

Greg,

              This agrees with what Jeff said.

              That is, the conditions under which ALL SLO are met is the intersection of service availability for each individual SLO.

              As I said (separately and very recently), however, there is a very high likelihood of correlated failures for many SLO values (e.g. – excessive packet loss and delay variation are very likely to occur in the same outage).

              For any service having a relatively high availability, it is extremely likely that – outside of infrequent outages – the observed behavior with respect to all SLO will be that the service is well within bounds.  If this is not the case, and that fact is detected by the service (provider), chances are very good that there will be some corrective response aimed at returning the service to the condition where the service performance with respect to all SLO is again well within bounds.

--
Eric

From: Greg Mirsky <[email-masked]>
Sent: Tuesday, June 2, 2020 12:00 PM
To: Eric Gray <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; Kiran Makhijani <[email-masked]>; [email-masked]; Eric Gray <eric.gray=[email-masked]>
Subject: Re: [Teas-ns-dt] Availability
Importance: High

Hi Eric,
it is much better to have a use case to discuss, thank you. Do you think that availability includes all performance-related parameters, e.g., packet loss ratio, latency, and jitter? My interpretation of the definition in the draft is that availability is the intersection of time periods when each performance-related SLO is within the agreed range. And I think that it is important to see it as an intersection because if during the same period, for example, the packet loss ratio is 0% but latency is above its threshold, that period of time is considered as unavailability period for the given TS. What do you think?

Regards,
Greg

On Tue, Jun 2, 2020 at 8:48 AM Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Jeff,

              I have to disagree.

--
Eric

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeff Tantsura
Sent: Monday, June 1, 2020 6:07 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Availability

Hi Greg,

Example:

Cheers,
Jeff

Regards,
Greg

Example:

Hope this clarifies

Cheers,
Jeff

Regards,
Greg

Cheers,
Jeff

Regards,
Greg

Cheers,
Jeff

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 3 Jun 2020 15:55:46 +0000

Hi Eric and Greg,

I also think that the service availability should be based on the conformant of all SLOs listed in the SLA. Failure in meeting any one of the SLOs should be considered unavailable for the service.

And in addition to the failure or outage case, some SLO of one network slice may be impacted by the misbehavior of traffic in other network slices. Thus to meet the required availability, the impact between slices also needs to be taken into consideration.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Wednesday, June 3, 2020 12:39 AM
To: Greg Mirsky <[email-masked]>
Cc: Eric Gray <eric.gray=[email-masked]>; Jeff Tantsura <[email-masked]>; Kiran Makhijani <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] Availability

Greg,

--
Eric

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 2, 2020 12:00 PM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>
Subject: Re: [Teas-ns-dt] Availability
Importance: High

Hi Eric,

Regards,
Greg

              I have to disagree.

--
Eric

Hi Greg,

Example:

Cheers,
Jeff

Regards,
Greg

Example:

Hope this clarifies

Cheers,
Jeff

Regards,
Greg

Cheers,
Jeff

Regards,
Greg

Cheers,
Jeff

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Jun 2020 14:50:58 +0000

> I also think that the service availability should be based on the conformant of all SLOs listed in the SLA. Failure in meeting any one of the SLOs should be considered unavailable for the service.
 
I agree.

> And in addition to the failure or outage case, some SLO of one network slice may be impacted by the misbehavior of traffic in other network slices. Thus to meet the required availability, the impac…

The impact of any misbehaviour, accidents, or any problem to keep enough capacity to satisfy committed contracts are all reasons why there's a failure, and consequently, reduced availability.

But I don't think it matters in the metric what the reason for the failure was.

Jari

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 11 Jun 2020 08:47:36 -0700

I agree with both points, and this is what the document meant to say, SLA = Σ(SLO1 && SLOn). I’ll add some text
Every SLA is slice specific, user is only interested if their SLOs are met, anything outside of this particular set of SLO’s is irrelevant.

Cheers,
Jeff