Subject: Re: [manet] DLEP and latency metric

From: John Dowdell <[email-masked]>
Date: Wed, 4 May 2016 12:42:54 +0100

I know we’re all a bit tied up with various last calls but can I ask for adjudication on this point? The current draft is ambiguous as to whether the latency metric includes the current queuing delay, taking account of how full or not the queue is at the sampling instant, or a notional “no traffic" delay (in the same manner as for the bandwidth metric), and there are polarised views for and against.

Just that I’m keen to get this one clarified one way or the other.

Following Stan’s proposal below, can I propose that the Latency Metric is measured in absence of traffic, and that an extension metric for Link Utilisation (which could provide metrics plural) is written up?

Regards
John

> On 27 Apr 2016, at 07:43, Teco Boot <[email-masked]> wrote:
> 
>> 
>> Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <[email-masked]> het volgende geschreven:
>> 
>> John,
>> 
>> Speaking as a co-author and a DLEP implementer,
>> 
>> On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <[email-masked]> wrote:
>> Hi all
>> 
>> A question has arisen as to whether the Latency metric should include queueing delay in the modem.
>> 
>> It has long been held that the bandwidth metric is measured in the absence of traffic (though the metric descriptions in 10.14 and 10.15 of Current Data Rate are ambiguous on this point), yet section 10.16 of -22 states ...
>> 
>> Yes, that's the way my implementation went. I don't see a use case for a bandwidth metric that attempts to take traffic into account, and it seems to me like such a metric could (would) fluctuate wildly. From my experience, the "interesting statistic" was always "how fast is the pipe?" Trying to factor traffic into account can have really weird side-effects - for instance, I remember a radio implementation that reported a "Current Data Rate" of 0 on an idle link (because, after all, no traffic was flowing)... that drove the router nuts, since it saw a "broken" (or nearly broken) link.
>> 
>> 
>> 
>> " Latency: A 64-bit unsigned integer, representing the transmission delay, in microseconds, that a packet encounters as it is transmitted over the link.”
>> 
>> … which suggests that queuing delay should be included.
>> 
>> Much as in the case above, I can't see a use case for a "Latency" metric *without* queueing delay.
> 
> I don't get this. Above, you suggest traffic is not taken into account. Here, you suggest queuing delay (caused by traffic?) is taken into account.
> 
> I suggest packet handling delay for a single packet on an idle medium is taken into account. Delay caused by filled up queues is not. Queue depth would be another metric. Which would fluctuate wildly^^2. And could be a complex composite metric when *FQ is used. See RFC 7567 / BCP 197 on what packet forwarding devices SHOULD do.
> 
> Teco
> 
> 
>> 
>> 
>> There are positive and negative connotations; a modem queue that suddenly becomes full might not have any more data queued to it, or a DLEP-powered routing algorithm might choose another modem instead, allowing the queue to subside, but that might not be what the system integrator wanted to happen.
>> 
>> And that would depend on a lot of code that outside the scope of the DLEP spec - specifically, it depends on how an algorithm actually *deals* with the DLEP metrics supplied.
>> 
>> Having said all of that, I can see a possibility for a couple of follow-on metrics for a DLEP extension - the first would be a "Link Utilization" metric. The other would be a "Propagation delay" metric, based on the physical properties of the transmission medium.
>> 
>> Just a thought.
>> 
>> Regards,
>> Stan
>> 
>> 
>> _______________________________________________
>> manet mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 4 May 2016 12:20:19 +0000

Just a word of caution.

I remember experimenting with some manet related protocols that had all types of metrics and weighting.  When we applied all of these complexities to an environment with varying traffic we eventually zeroed out most of the options as they were effectively meaningless.  I suspect queueing delay would be one of those here.  That effort was probably 8 to 10 years ago.   Unfortunately, I don’t think I can legally say much more than that at this time.

Will

From: manet <[email-masked]<mailto:[email-masked]>> on behalf of John Dowdell <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 4, 2016 at 7:42 AM
To: MANET IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [manet] DLEP and latency metric

Regards
John

On 27 Apr 2016, at 07:43, Teco Boot <[email-masked]<mailto:[email-masked]>> wrote:

Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

John,

On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <[email-masked]<mailto:[email-masked]>> wrote:
Hi all

Teco

Just a thought.

Regards,
Stan

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

---

From: "MATTY, Steven" <[email-masked]>
Date: Wed, 4 May 2016 12:29:03 +0000

+1

I don’t see how applying queuing delay would work – if QoS (e.g. 802.1Q-2005 or 802.1Q-2011 or other) queuing is applied on incoming traffic then some of it may well get a lower delay than others – but there is only one ‘latency’ specified in DLEP – so an extension to provide queuing delay metrics would seem the most sensible option to me.

From: manet [mailto:[email-masked]] On Behalf Of John Dowdell
Sent: Wednesday, May 04, 2016 12:43 PM
To: MANET IETF
Subject: Re: [manet] DLEP and latency metric

Regards
John

John,

Teco

Just a thought.

Regards,
Stan

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 May 2016 12:38:40 +0000

Was the suggestion to include an empty queuing delay, i.e. it included everything, but in the case where the queue was empty? That sounds like a sensible approach, assuming it’s reasonably stable.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

Sent: 04 May 2016 12:43

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Regards
John

John,

Teco

Just a thought.

Regards,
Stan

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: John Dowdell <[email-masked]>
Date: Wed, 4 May 2016 14:08:59 +0100

> On 4 May 2016, at 13:38, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> Was the suggestion to include an empty queuing delay, i.e. it included everything, but in the case where the queue was empty?

Yes that is my proposal, or actually my seconding of Stan’s proposal, assuming I understood Stan correctly.

Regards
John

> That sounds like a sensible approach, assuming it’s reasonably stable.
>  
> --
> 
> Christopher Dearlove
> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Dowdell
> Sent: 04 May 2016 12:43
> To: MANET IETF
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
> *** WARNING ***
> On 27 Apr 2016, at 07:43, Teco Boot <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <[email-masked] <mailto:[email-masked]>> het volgende geschreven:
> 
> John,
> 
> On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all
>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 May 2016 11:18:54 -0400

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

On Wed, May 4, 2016 at 9:08 AM, John Dowdell <[email-masked]>
wrote:

> Was the suggestion to include an empty queuing delay, i.e. it included
> everything, but in the case where the queue was empty?
>
>
> *--*
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> *From:* manet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *John Dowdell
> *Sent:* 04 May 2016 12:43
> *To:* MANET IETF
> *Subject:* Re: [manet] DLEP and latency metric
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> *Consider carefully whether you should click on any links, open any
> attachments or reply.For information regarding **Red Flags** that you can
> look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> *If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
> **** **WARNING ******
> I know we’re all a bit tied up with various last calls but can I ask for
> adjudication on this point? The current draft is ambiguous as to whether
> the latency metric includes the current queuing delay, taking account of
> how full or not the queue is at the sampling instant, or a notional “no
> traffic" delay (in the same manner as for the bandwidth metric), and there
> are polarised views for and against.
>
> Following Stan’s proposal below, can I propose that the Latency Metric is
> measured in absence of traffic, and that an extension metric for Link
> Utilisation (which could provide metrics plural) is written up?
>
> Regards
> John
>
>
> It has long been held that the bandwidth metric is measured in the absence
> of traffic (though the metric descriptions in 10.14 and 10.15 of Current
> Data Rate are ambiguous on this point), yet section 10.16 of -22 states ...
>
> Yes, that's the way my implementation went. I don't see a use case for a
> bandwidth metric that attempts to take traffic into account, and it seems
> to me like such a metric could (would) fluctuate wildly. From my
> experience, the "interesting statistic" was always "how fast is the pipe?"
> Trying to factor traffic into account can have really weird side-effects -
> for instance, I remember a radio implementation that reported a "Current
> Data Rate" of 0 on an idle link (because, after all, no traffic was
> flowing)... that drove the router nuts, since it saw a "broken" (or nearly
> broken) link.
>
>
>
> " Latency: A 64-bit unsigned integer, representing the transmission delay,
> in microseconds, that a packet encounters as it is transmitted over the
> link.”
>
> I don't get this. Above, you suggest traffic is not taken into account.
> Here, you suggest queuing delay (caused by traffic?) is taken into account.
>
> I suggest packet handling delay for a single packet on an idle medium is
> taken into account. Delay caused by filled up queues is not. Queue depth
> would be another metric. Which would fluctuate wildly^^2. And could be a
> complex composite metric when *FQ is used. See RFC 7567 / BCP 197 on what
> packet forwarding devices SHOULD do.
>
> Teco
>
>
>
>
>
> There are positive and negative connotations; a modem queue that suddenly
> becomes full might not have any more data queued to it, or a DLEP-powered
> routing algorithm might choose another modem instead, allowing the queue to
> subside, but that might not be what the system integrator wanted to happen.
>
> And that would depend on a lot of code that outside the scope of the DLEP
> spec - specifically, it depends on how an algorithm actually *deals* with
> the DLEP metrics supplied.
>
> Having said all of that, I can see a possibility for a couple of follow-on
> metrics for a DLEP extension - the first would be a "Link Utilization"
> metric. The other would be a "Propagation delay" metric, based on the
> physical properties of the transmission medium.
>
> Just a thought.
>
> Regards,
> Stan
>
>
> [email-masked]
> [email-masked]

---

From: "A .Riley Eller" <[email-masked]>
Date: Wed, 4 May 2016 10:20:37 -0700

Modem-based priority queuing is a common feature with performance
characteristics that may elude the ability of a router to make accurate
predictions of behavior or performance. In the case of 802.11, as an
example of real-world complex interactions, higher priority traffic has a
significantly lower channel acquisition time (and therefore a higher frame
capacity) than bulk traffic. Protocol data unit aggregation, in turn, may
or may not "piggyback" lower priority packets into a frame being treated as
high priority. It makes great sense to report utilization and queuing delay
on a per-priority basis.

In a previous heterogeneous MANET exercise, my team made very effective use
of reporting utilization and queuing delay on a per-ToS basis plus a
single, total link capacity.

Modems lacking priority queues could report aggregates within the highest
priority class. Routers lacking awareness of priority could sum the
capacities and average, or select the maximum from among, the latencies.

I could try my hand at editing DLEP-22 if this idea appeals to the group.

On May 4, 2016, at 8:21 AM, Stan Ratliff <[email-masked]> wrote:

All,

So, my proposal was:

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 May 2016 15:03:27 -0400

Hi!

Response inline - Speaking as a DLEP co-author, and WG participant:

On Wed, May 4, 2016 at 1:20 PM, A .Riley Eller <[email-masked]> wrote:

> In a previous heterogeneous MANET exercise, my team made very effective
> use of reporting utilization and queuing delay on a per-ToS basis plus a

I think, as John and Neil Viberg mentioned in another email, this is a good
subject for a DLEP extension, and I'd be really interested in being
involved. But process-wise, I don't think modifying DLEP-22 is the way to
go. I believe this is a big enough change that we'd have to pull DLEP back
from "Request to Publish" status, and I don't think it's as straightforward
as it seems at first glance - I think there are some subtleties that will
need to be discussed to make sure the extension applies to a broad set of
modems capable of multiple priorities.

So, I'm in agreement with Neil - I think we should leave the existing draft
as-is, and approach this in a DLEP Extension.

Other thoughts?

Regards,
Stan

>> attachments or reply.For information regarding **Red Flags** that you
>> can look out for in emails you receive, click here
>> It has long been held that the bandwidth metric is measured in the
>> absence of traffic (though the metric descriptions in 10.14 and 10.15 of
>> Current Data Rate are ambiguous on this point), yet section 10.16 of -22
>> states ...
>>
>> " Latency: A 64-bit unsigned integer, representing the transmission
>> delay, in microseconds, that a packet encounters as it is transmitted over
>> the link.”
>>
>> Having said all of that, I can see a possibility for a couple of
>> follow-on metrics for a DLEP extension - the first would be a "Link
>> Utilization" metric. The other would be a "Propagation delay" metric, based
>> on the physical properties of the transmission medium.
>>
>> Just a thought.
>>
>> Regards,
>> Stan
>>
>>