Subject: Re: [manet] DLEP and latency metric

From: "Viberg, Neil" <[email-masked]>
Date: Wed, 4 May 2016 17:20:58 +0000

Stan,

I agree with your ideas about latency *if* there is only one priority. If there is more than one priority then a single "latency" number doesn't mean a lot. You'd need one per priority for full characterization. For the time being I would think a rational approach for a vendor would be to derive latency *without* queueing when multiple priorities are configured. This approach would suggest doing the same for a single priority for consistency but is not a requirement. An extension for queuing delay that allows for multiple return values could then be added at which point the latency could logically be tightened to exclude queueing delay if the extension is used.

I second your proposal to leave the current latency alone.
Cheers,
Neil

> Date: Wed, 4 May 2016 11:18:54 -0400
> From: Stan Ratliff <[email-masked]>
> To: John Dowdell <[email-masked]>
> Cc: "Dearlove, Christopher \(UK\)" <[email-masked]>,
>             MANET IETF <[email-masked]>
> Subject: Re: [manet] DLEP and latency metric
> Message-ID:
>             <CALtoyon4OU0K0WmZDqW8kdkcQqMyW6_hjqzwyUki95hnK5hA=[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> All,
>
> That actually wasn't my proposal. I'll attempt to clarify. First off, the
> text from DLEP-22 on Latency, in Section 10.16:
>
> "The Latency value is reported as transmission delay. The calculation
> of latency is implementation dependent. For example, the latency may
> be a running average calculated from the internal queuing."
>
> So, the text doesn't mandate that queuing delay be included, it just lists
> that as an example. That being said, I'm one who doesn't see that a Latency
> calculation is all that interesting *UNLESS* you include queuing delay.
> Otherwise, to me anyway, it's along the lines of "You know Mr. Router, my
> normal bit-twiddling delay + Propagation Delay on this RF link is about
> <blah> ms. What I'll leave unsaid is how bad things get if/when a queue of
> traffic exists for said link, but that's OK, isn't it? What's some unknown
> (unreported) amount of delay between friends?"
>
> The first calculation (ignoring queuing delay) is more or less "Here's my
> *best case* Latency". Add "some fudge-factor" to make it anywhere close to
> real.
>
> So, my proposal was:
> 1. Leave the bandwidth definition alone, in that it does *not* include
> current traffic on the link. It's an indication of "how fast is the pipe".
> 2. Leave the Latency stuff alone as well - yes, the example includes
> queuing delay. But it's only an example; nothing stops a vendor from
> implementing Latency *without* queuing delay, although I think that's a bad
> idea.
> 3. Look at the possibility of augmenting the statistics to make everyone
> happy. Specifically, add
>     a. A "Bandwidth Utilization" metric. That way, a router could see
> something like "CDRT on the link is 20Mbps, and the link is currently at
> 80% capacity).
>     b. A "Propagation Delay" metric, that is *exactly* what John has been
> discussing. That metric is "modem bit-twiddling time, in case the frame has
> to be somehow morphed for transmission, PLUS RF propagation delay." That
> number would change if, for instance, the modem changes modulation
> techniques on the link, but would otherwise be pretty stable.
>
> OK, I'm running for the closet to jump into the flame-retardant suit... :-)
>
> Regards,
> Stan

---

From: John Dowdell <[email-masked]>
Date: Wed, 4 May 2016 19:05:47 +0100

> On 4 May 2016, at 18:20, Viberg, Neil <[email-masked]> wrote:
> 
> Stan,
>  
> I agree with your ideas about latency *if* there is only one priority. If there is more than one priority then a single “latency” number doesn’t mean a lot. You’d need one per priority for full characterization. For the time being I would think a rational approach for a vendor would be to derive latency *without* queueing when multiple priorities are configured. This approach would suggest doing the same for a single priority for consistency but is not a requirement. An extension for queuing delay that allows for multiple return values could then be added at which point the latency could logically be tightened to exclude queueing delay if the extension is used.

There are flow control and VLAN extensions written up in individual drafts. Check datatracker.ietf.org and search for DLEP. It therefore makes sense to include metrics to do with priority either in those drafts or in other extension drafts.

Regards
John
> > From: Stan Ratliff <[email-masked] <mailto:[email-masked]>>
> > To: John Dowdell <[email-masked] <mailto:[email-masked]>>
> > Cc: "Dearlove, Christopher \(UK\)" <[email-masked] <mailto:[email-masked]>>,
> >             MANET IETF <[email-masked] <mailto:[email-masked]>>
> >             <CALtoyon4OU0K0WmZDqW8kdkcQqMyW6_hjqzwyUki95hnK5hA=[email-masked] <mailto:CALtoyon4OU0K0WmZDqW8kdkcQqMyW6_hjqzwyUki95hnK5hA=[email-masked]>>