Subject: [manet] DLEP and latency metric

From: John Dowdell <[email-masked]>
Date: Tue, 26 Apr 2016 23:06:59 +0100

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

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

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.

Regards
John

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 26 Apr 2016 19:16:20 -0400

John,

Speaking as a co-author and a DLEP implementer,

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

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

Much as in the case above, I can't see a use case for a "Latency" metric
*without* queueing delay.

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

---

From: Teco Boot <[email-masked]>
Date: Wed, 27 Apr 2016 08:43:57 +0200

> Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <[email-masked]> het volgende geschreven:
> 
> John,
> 
> On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <[email-masked]> wrote:
> Hi all
> 
> 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.
> 
> 
> 
> 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

> 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]
> https://www.ietf.org/mailman/listinfo/manet