Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 04 Sep 2008 13:44:07 +0200

Hi,

I'd still like the authors to answer my comments on the "fail/pass" 
table at the end of section 4, which is not fully justified in the document.

As a reminder, here are a couple of "fail/pass" statements present in 
this table, which were pointed out as being doubtful:

- OLSR is said to "fail" the "loss response" criteria. However in the
quick justification in section 4, nothing is said about link hysteresis
strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR
"pass" this criteria.

- OLSR is said to "fail" the "control cost" criteria. However, simple
fisheye TTL strategy on OLSR control messages makes OLSR "pass" this
criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal
of Communication and Networks, 2004. Actually this paper even proves
that OLSR can thus reach the Gupta and Kumar bounds in terms of control
overhead scalability.

I am sure that other people would have additional question marks with 
this table. But for starters, the items above should be discussed.

regards,

Emmanuel

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 17:55:36 +0200

Hello,

May I bring my point of view.

Theoretically link hysteresis solution solves the issue of bad links. In practice, link hysteresis is not very efficient for at least 2 reasons. The link hysteresis solution is based on the reception of hello packets which are generally sent at lower throughput than data packets because hello packets are sent in broadcast. So hello packets have more chance to be received than data packets (see "grey zone" issue), all the more so OLSR tends to minimize the number of hops and so tends to choice the worst links. Furthermore, the packet loss is mainly due to the SINR variation which can be very huge depending on the material and the environment and link quality determined by link hysteresis can be in phase difference with the SNR variation. 

Best regards.

François

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Emmanuel Baccelli
Envoyé : jeudi 4 septembre 2008 13:44
À : [email-masked]
Objet : Re: [Roll] draft-ietf-roll-protocols-survey-00

Hi,

As a reminder, here are a couple of "fail/pass" statements present in this table, which were pointed out as being doubtful:

regards,

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 04 Sep 2008 18:39:44 +0200

Hi François,

thanks for your response. I have a couple of comments about it:

- do we have an understanding what kind of data traffic intensity we are 
targetting in Roll? This may be interesting to know, since it seems you 
have an idea about it.

- Link hysteresis is a mechanism to eliminate bad links, and some kind 
of metric in this sense. This mechanism is completely ignored in the 
document so far. So my comment is: "Take it into account".

- As to the efficiency of link hysteresis, it would be useful to gather 
the experience of people (there are many) who have implemented and 
tested OLSR with real devices. Moreover, we should get a quantitative 
appreciation about link hysteresis that could be compared to, say, 
TBRPF's corresponding mechanism that is said to "pass" the "loss" test 
in the document so far. Again, this should be justified.

cheers
Emmanuel

---

From: Philip Levis <[email-masked]>
Date: Thu, 4 Sep 2008 11:42:55 -0700

> strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR

I disagree. All link hysteresis does is smooth a noisy signal. This  
does not mean that links do not come and go. It can reduce the maximum  
frequency of advertised link state changes. It is important to note  
that this technique does have a cost, in terms of routing correctness  
and efficiency. I.e., a link can go to 0% suddenly yet hysteresis will  
prevent this change from propagating quickly (a basic property of  
smoothing). Nevertheless, it will propagate.

> that OLSR can thus reach the Gupta and Kumar bounds in terms of  

I think it's important to have a clear line defining what sufficiently  
demonstrates properties of a protocol. I think the paper has some  
interesting ideas, but it isn't a protocol specification, nor does it  
demonstrate a working protocol with real wireless behavior (e.g., link  
dynamics). Do you have running code?

Phil