Re: [manet] DLEP and latency metric

> On 4 May 2016, at 13:38, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> 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
> Senior Principal Engineer
> BAE Systems Applied Intelligence Laboratories
> __________________________________________________________________________
> 
> T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com <mailto:chris.dearlove@baesystems.com>
> 
> 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
> 
>  
> From: manet [mailto:manet-bounces@ietf.org <mailto:manet-bounces@ietf.org>] 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 ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>  
> 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 <teco@inf-net.nl <mailto:teco@inf-net.nl>> wrote:
>  
> 
> Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <ratliffstan@gmail.com <mailto:ratliffstan@gmail.com>> het volgende geschreven:
> 
> John,
> 
> Speaking as a co-author and a DLEP implementer,
> 
> On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <john.dowdell.ietf@gmail.com <mailto:john.dowdell.ietf@gmail.com>> 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
> manet@ietf.org <mailto:manet@ietf.org>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>  
> ********************************************************************
> 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.
> ********************************************************************
> 