Subject: Re: [manet] New revision of OLSRv2 metric draft released

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 08 Oct 2013 11:03:19 +0200

> Can you specify what you would like to see? Link asymmetry? Or data
> on ACK loss and how this relates to MANET protocol packet loss?

I want to see experimental data that shows whether backwards packet
loss with detection of asymmetric neighbours (which is what Henning's
draft proposes) does yield results that are good enough in practice.
Ideally, I'd like to see a comparison with bidirectional packet loss
(which is what ETX/ETT measure).

-- Juliusz

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 8 Oct 2013 14:26:23 +0000

> (which is what ETX/ETT measure).

So, I assume that you are *volunteering* to produce this data? Stating what you "want to see" is better received when accompanied by an offer to help *produce it*. 

Stan

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

---

From: Henning Rogge <[email-masked]>
Date: Tue, 8 Oct 2013 16:32:21 +0200

I will try to get some data too, but I just came back from a longer
business trip.

I think we also need a discussion in the working group about the
linkspeed part of the DAT metric.

With only 24 bits of output, we cannot handle both gigabit per seconds
and very slow links. Do we want to limit the range of the metric or do
we introduce a shaping function that compresses the linkspeed?

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 08 Oct 2013 08:59:43 -0700

> we introduce a shaping function that compresses the linkspeed?

Henning,

A practical observation.  No radio network segment will be larger than M
bits -- you're spectrum limited, not EE limited.  And the asymmetric
links are likely to be the radio ones.  

So while you may want to be able to characterize a G-bit link, getting
it gnats-eyebrow accurate won't matter much.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 8 Oct 2013 16:04:56 +0000

You have to shape the link speed no matter what, because we need a metric where high is bad and low is good. And any inversion function is a shaping. In addition the metric will be treated additively, so you need t consider how that will interact with your shaping.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 08 October 2013 15:32
To: Stan Ratliff (sratliff)
Cc: [email-masked] List; Juliusz Chroboczek
Subject: Re: [manet] New revision of OLSRv2 metric draft released

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Henning Rogge

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 8 Oct 2013 16:10:46 +0000

http://en.wikipedia.org/wiki/Wireless_Gigabit_Alliance
suggests some people are working on  rates above a Gbit/s. Which is quite plausible in the 60 GHz band.

But metric should not be simply linear with data rate, as previously noted.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rex Buddenberg
Sent: 08 October 2013 17:00
To: Henning Rogge
Cc: [email-masked] List; Juliusz Chroboczek; Stan Ratliff (sratliff)
Subject: Re: [manet] New revision of OLSRv2 metric draft released

Henning,

---

From: Henning Rogge <[email-masked]>
Date: Tue, 8 Oct 2013 18:15:41 +0200

Yes,

but at the moment the DAT metric IS linear (inverse linear) to the
bitrate, which either will give us a large minimum bitrate or a low
maximum one, depending on the factor we apply.

So we have to consider using a non-linear function when applying the
the bitrate to the metric.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 8 Oct 2013 16:24:34 +0000

What's the minimum bit rate we actually expect to use?

I'll take a stab at 2400 bits/s, or just possibly 1200 bits/s, both used at HF. We are after all carrying IP traffic, and need to carry some traffic as well as the OLSRv2 packets (which would need some compression).

So absolute worst case I suggest is bitrate in kbit/s. 24 bits then gives us up to 16 Gbit/s.

Actually I think I'd shift that up, as I don't really see OLSRv2 being used quite that far down, and 16 Gbit/s could be exceeded in the foreseeable future. (Let's also not forget possible free space optical comms.)

This isn't intended to agree (but nor disagree) that this is a good approach, I'm just considering what if this approach is used here.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 08 October 2013 17:16
To: Dearlove, Christopher (UK)
Cc: Rex Buddenberg; [email-masked] List; Juliusz Chroboczek; Stan Ratliff (sratliff)
Subject: Re: [manet] New revision of OLSRv2 metric draft released

Yes,

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 8 Oct 2013 18:33:38 +0200

You forgot we need some "space" for the packet-loss part of the metric too.

So if we allow an ETX of 1-4, we can still do 1024 bit/s to 4 gbit/s.

That might be an interesting range.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 8 Oct 2013 19:26:34 +0200

I use reserved blocks for certain link types. At the low end, links are wired, e.g. a bundle 10G fibers would have metric 1. At the high end, the values are used for redistributed default gateways. Could be less than 1024bps. 802.11 type of links are somewhere in the middle. Links with shared medium like 802.11 (or 10Base5 ;-) have a multiplier.

Problem with this model is that it is less plug & play.

Teco

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 8 Oct 2013 18:32:59 +0100

I think there will often be cases that are a bit ad hoc (if you'll pardon the expression) and suitable for specific networks. Fortunately we have a private/experimental block for those. If any of them got into a widely deployed network we could standardise then.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 8 Oct 2013, at 18:26, Teco Boot <[email-masked]> wrote:
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 9 Oct 2013 14:45:33 +0200

On 10/08/2013 06:04 PM, Dearlove, Christopher (UK) wrote:
> You have to shape the link speed no matter what, because we need a
> metric where high is bad and low is good. And any inversion function
> is a shaping. In addition the metric will be treated additively, so
> you need t consider how that will interact with your shaping.

Yes, that is right.

But at the moment we just use loss divided by linkspeed (with a constant
factor), which is something roughly proportional to the airtime used by
the transmission.

If we use a non-linear function for mapping the linkspeed to the cost,
we get a better range of linkspeed, but loose the airtime meaning.

I think we should NOT use the encoding of 1 for the best linkspeed
combined with "no loss". If we do, the second best loss we can signal
become "ETX 2.0", which is a huge step.

I would suggest using 4 as the minimal setting of the metric, which
means we can signal "ETX 1.25" (20% loss) and ETX 1.5 (33% loss) as the
next steps.

I agree with Teco that we should have at least the capability to signal
a link-speed of 1 GBit/s.

(I hope I did not again introduced a math error in this calculation)

  1 GBit/s, ETX 1.0: cost        4 (compr.        4: a=  3,b= 0).
  1 GBit/s, ETX 4.0: cost       16 (compr.       16: a= 15,b= 0).
100 MBit/s, ETX 1.0: cost       41 (compr.       41: a= 40,b= 0).
100 MBit/s, ETX 4.0: cost      164 (compr.      164: a=163,b= 0).
 10 MBit/s, ETX 1.0: cost      410 (compr.      410: a= 76,b= 1).
 10 MBit/s, ETX 4.0: cost     1640 (compr.     1640: a=217,b= 2).
  1 MBit/s, ETX 1.0: cost     4096 (compr.     4096: a= 15,b= 4).
  1 MBit/s, ETX 4.0: cost    16384 (compr.    16384: a=  3,b= 6).
100 KBit/s, ETX 1.0: cost    41943 (compr.    41984: a= 73,b= 7).
100 KBit/s, ETX 4.0: cost   167772 (compr.   167680: a= 71,b= 9).
 10 KBit/s, ETX 1.0: cost   419430 (compr.   419584: a=153,b=10).
 10 KBit/s, ETX 4.0: cost  1677722 (compr.  1679104: a=159,b=12).
  1 KBit/s, ETX 1.0: cost  4194304 (compr.  4194048: a=255,b=13).
  1 KBit/s, ETX 4.0: cost 16777216 (compr. 16776960: a=255,b=15).

What do you think about this distribution?

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 09 Oct 2013 15:31:32 +0200

> So, I assume that you are *volunteering* to produce this data?

I'll certainly be glad to work with Henning on producing the suitable
data.  (We'll probably be meeting in May at WBM, that could be an
opportunity do work on that.)

> Stating what you "want to see" is better received when accompanied
> by an offer to help *produce it*.

Sorry, Stan, but it doesn't work that way.  It was Henning's choice to
use a unidirectional loss metric rather than one of the bidirectional
metrics that have been studied in the peer-reviewed literature; and
the MANET group has chosen to go with it.  It is the duty of the
proponents to justify their choice, in particular by showing that it
does not behave significantly worse than the better studied metrics.

Or are you suggesting that as far as the IETF MANET group is concerned,
implementations and experimental data are not desirable?

-- Juliusz

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 9 Oct 2013 16:06:48 +0000

> does not behave significantly worse than the better studied metrics.

Sorry, Juliusz, but it *does* work that way, your opinion notwithstanding. If you're *that* concerned about an aspect of a draft, then how about producing data (or references) that show it to be incorrect? I don't remember seeing such as of this point.

> implementations and experimental data are not desirable?

….ahh, the smell of absurdity... 

Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 9 Oct 2013 20:08:27 +0200

Op 9 okt. 2013, om 15:31 heeft Juliusz Chroboczek <[email-masked]> het volgende geschreven:

> the MANET group has chosen to go with it.
Why do you think the MANET group has chosen?

I think the opposite is true. We recognized metrics for wireless link are not symmetric. ETX/ETT has to be improved to take this into account.

I think Henning proposed a simple straightforward mechanism, without a need for signaling over the air. But yes, it misses the ACK-loss component. If we add signaling, I suggest to use an improved ETT in Henning's proposal with feedback on missed ACKs and not use the neighbor loss ratio, or, at least use a weight factor for it to adjust for the smaller ACK frames.

Teco 

>  It is the duty of the

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 09 Oct 2013 21:55:12 +0200

>> It is the duty of the proponents to justify their choice, in
>> particular by showing that it does not behave significantly worse
>> than the better studied metrics.

> If you're *that* concerned about an aspect of a draft, then how
> about producing data (or references) that show it to be incorrect?

As I've mentioned in a previous mail, my intuition fully agrees with
Henning's -- I'm pretty confident that Henning's metric works almost
as well as ETT.

However, while both Henning and I have spent significant amounts of
our lives staring at packet loss figures in mesh networks, all we have
at this time is the intuition of two people.  Hard data that confirms
our intuitions would certainly be a good thing to have -- and, I'd
argue, a prerequisite to promoting Henning's draft to RFC.

-- Juliusz

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 9 Oct 2013 20:10:44 +0000

> argue, a prerequisite to promoting Henning's draft to RFC.

Then perhaps the issue here is that you and I are in "violent agreement" - data is a good thing. All I'm saying is, in addition to calling for it, let's all think about how we can help produce it. 

Stan

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 09 Oct 2013 23:12:16 +0200

>> Hard data that confirms our intuitions would certainly be a good
>> thing to have -- and, I'd argue, a prerequisite to promoting
>> Henning's draft to RFC.

> Then perhaps the issue here is that you and I are in "violent
> agreement" - data is a good thing.

I may have misunderstood, but I still think we have different
opinions.  You appear to consider hard data as a mere luxury -- a nice
thing to have --, while I happen to believe it's a necessity.

> All I'm saying is, in addition to calling for it, let's all think
> about how we can help produce it.

Yes.  I have no doubts about Henning's scientific integrity, and I'll
be glad to work with him on setting up a suitable experiment.

-- Juliusz

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 10 Oct 2013 01:46:51 +0000

> thing to have --, while I happen to believe it's a necessity.

You're dead wrong.

Stan