Subject: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss

From: Gregory Mirsky <[email-masked]>
Date: Tue, 19 Mar 2013 02:14:35 +0000

Dear Authors, et al.,
As mentioned at the mike during IS-IS WG meeting in Orlando, I believe that three parameters, Link Delay, Delay Variation, and Link Loss are per priority/Traffic Class. Other link characteristics introduced in draft-previdi-isis-te-metric-extensions- and draft-ietf-ospf-te-metric-extensions- documents, Residual Bandwidth and Available Bandwidth, might not have distinct per priority connotation.

I think that per priority advertisement does not imply dynamic queuing being included, not suggest how these metrics get their values (dynamic measurement or estimate), but allows more realistically characterize a link.

Comments, suggestions are welcome and greatly appreciated.

        Regards,
                Greg

---

From: <[email-masked]>
Date: Tue, 19 Mar 2013 02:55:34 +0000

It was considered before and there was certainly no consensus (really only one or two ppl brought it up)that per priority was worth the complexity. My personal opinion is that since we are not trying to measure queuing delay (in fact there has been strong desire to avoid any queue delay) that we don't need per queue support.

Best,

Spencer

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Monday, March 18, 2013 09:14 PM Central Standard Time
To: [email-masked] <[email-masked]>; Giacalone, Spencer (Financial&Risk); [email-masked] <[email-masked]>; John E Drake <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss

Dear Authors, et al.,

        Regards,
                Greg

---

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Mar 2013 05:05:14 -0400

I agree with Spencer that I don't see the extra information on a per-queue
being useful if we are not measuring dynamic queuing behavior and delay.

How do you see these values being different?   Where would you get them
from while avoiding the concerns about a traffic-dependent feedback loop?

Alia
On Mar 19, 2013 3:14 AM, "Gregory Mirsky" <[email-masked]>
wrote:

>  Dear Authors, et al.,
> As mentioned at the mike during IS-IS WG meeting in Orlando, I believe
> that three parameters, Link Delay, Delay Variation, and Link Loss are per
> priority/Traffic Class. Other link characteristics introduced in
> draft-previdi-isis-te-metric-extensions- and
> draft-ietf-ospf-te-metric-extensions- documents, Residual Bandwidth and
> Available Bandwidth, might not have distinct per priority connotation.
>
> I think that per priority advertisement does not imply dynamic queuing
> being included, not suggest how these metrics get their values (dynamic
> measurement or estimate), but allows more realistically characterize a link.
>
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 20 Mar 2013 17:15:51 +0000

Hi Alia, et al.,
I was thinking about reflecting queuing without actually measuring it. I think that major concern with measuring dynamic queuing is that we have only active, including synthetic, measuring methods that change the process, at least that is to the best of my knowledge. But there're discussions on passive and/or hybrid methods that will be less distractive to the traffic. But there's another approach that I see as most practical at this time - AQM. AQM can be expressed in maximum queuing delay and it will exactly characterize unidirectional delay, delay variation on the given link.
Again, it might not happen tomorrow but I believe that it is beneficial to make tool flexible for the future, perhaps near future.

    Regards,
        Greg

________________________________
From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, March 20, 2013 2:05 AM
To: Gregory Mirsky
Cc: Clarence Filsfils; [email-masked]; [email-masked]; [email-masked]; [email-masked]; John E Drake; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss

I agree with Spencer that I don't see the extra information on a per-queue being useful if we are not measuring dynamic queuing behavior and delay.

How do you see these values being different?   Where would you get them from while avoiding the concerns about a traffic-dependent feedback loop?

Alia

On Mar 19, 2013 3:14 AM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:
Dear Authors, et al.,
As mentioned at the mike during IS-IS WG meeting in Orlando, I believe that three parameters, Link Delay, Delay Variation, and Link Loss are per priority/Traffic Class. Other link characteristics introduced in draft-previdi-isis-te-metric-extensions- and draft-ietf-ospf-te-metric-extensions- documents, Residual Bandwidth and Available Bandwidth, might not have distinct per priority connotation.

        Regards,
                Greg

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 20 Mar 2013 20:02:12 +0000

Making it to OSPF WG, finally.

________________________________
From: Gregory Mirsky
Sent: Wednesday, March 20, 2013 10:16 AM
To: 'Alia Atlas'
Cc: Clarence Filsfils; [email-masked]; [email-masked]; [email-masked]; [email-masked]; John E Drake; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss

Hi Alia, et al.,

    Regards,
        Greg

Alia

        Regards,
                Greg

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 21 Mar 2013 20:28:22 -0400

Greg,

Did I mention I hate top posting.  :-)

Just going with the precedence of the thread.  See inline.

Curtis

In message <[email-masked]>
Gregory Mirsky writes:
> 
> Hi Alia, et al.,
>  
> I was thinking about reflecting queuing without actually measuring
> it. I think that major concern with measuring dynamic queuing is that
> we have only active, including synthetic, measuring methods that
> change the process, at least that is to the best of my knowledge. But
> there're discussions on passive and/or hybrid methods that will be
> less distractive to the traffic. But there's another approach that I
> see as most practical at this time - AQM. AQM can be expressed in
> maximum queuing delay and it will exactly characterize unidirectional
> delay, delay variation on the given link.

AQM is queue management, therefore a measurement reflecting AQM is
reflecting queuing delay.  AQM is not a form of magic - there is still
a queue and it is still affected by the traffic load.

The point of not reflecting queuing delay is to avoid any chance of
oscillation.  Absent that a lot more work has to go into assuring
stability.

The same applies to per-TC delay.  The traffic classes only differ in
their queuing behavior.  All that can be said about TC is that any
measurements that may be subject to queuing must avoid any
non-negligible affects of traffic load by making use of a sufficiently
high queuing priority such that very little traffic exists at the same
or more preferred priority.  This implies measurement at the same
priority as control traffic or at a higher priority.

These are the reasons why there is only one delay value (or min/max
pair for LAG or composite link or other uses).

> Again, it might not happen tomorrow but I believe that it is
> beneficial to make tool flexible for the future, perhaps near future.
>  
>     Regards,
>         Greg
>  
> Cc: Clarence Filsfils; [email-masked];
>     [email-masked]; [email-masked];
>     [email-masked]; John E Drake; [email-masked]; [email-masked]
> I agree with Spencer that I don't see the extra information on a
> per-queue being useful if we are not measuring dynamic queuing
> behavior and delay.
>  
> How do you see these values being different?   Where would you get
> them from while avoiding the concerns about a traffic-dependent
> feedback loop?
>  
> Alia
>  
> that three parameters, Link Delay, Delay Variation, and Link Loss are
> per priority/Traffic Class. Other link characteristics introduced in
> draft-ietf-ospf-te-metric-extensions- documents, Residual Bandwidth
> and Available Bandwidth, might not have distinct per priority
> connotation.
>  
> being included, not suggest how these metrics get their values
> (dynamic measurement or estimate), but allows more realistically
> characterize a link.
>

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Fri, 22 Mar 2013 14:42:32 +0000

Hi Greg

Like Curtis says we measure 1 delay value at a high priority in order to remove queuing effects.   
I think advertizing of one delay value (Or range as we have it now with offsets)  per TE "link" not per priority is the right model.

Cheers,
Don 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Thursday, March 21, 2013 8:28 PM
To: Gregory Mirsky
Cc: [email-masked]; Clarence Filsfils; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] IGP-TE extensions for unidirectional Link Delay, Delay Variation, and Link Loss

Greg,

Curtis

Gregory Mirsky writes:
> 
> Hi Alia, et al.,
>  
> I was thinking about reflecting queuing without actually measuring it. 
> I think that major concern with measuring dynamic queuing is that we 
> have only active, including synthetic, measuring methods that change 
> the process, at least that is to the best of my knowledge. But 

AQM is queue management, therefore a measurement reflecting AQM is reflecting queuing delay.  AQM is not a form of magic - there is still a queue and it is still affected by the traffic load.

The point of not reflecting queuing delay is to avoid any chance of oscillation.  Absent that a lot more work has to go into assuring stability.

The same applies to per-TC delay.  The traffic classes only differ in their queuing behavior.  All that can be said about TC is that any measurements that may be subject to queuing must avoid any non-negligible affects of traffic load by making use of a sufficiently high queuing priority such that very little traffic exists at the same or more preferred priority.  This implies measurement at the same priority as control traffic or at a higher priority.

These are the reasons why there is only one delay value (or min/max pair for LAG or composite link or other uses).