Subject: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-04.txt

From: [email-masked]
Date: Wed, 21 Jan 2009 15:15:01 -0800 (PST)

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

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 22 Jan 2009 11:26:09 +0100

Hi,

thanks for submitting the new version of the ID.
Here my comments:

- Generally, I would prefer to separate the evaluation metrics and the
survey of protocols according to these metrics in two different
documents. It could be dangerous to mix these two aspects within the
same document as the choice of metrics may be influenced by the choice
of the protocols to be considered. Also, it would ease the addition of a
routing protocol later on without changing the evaluation criteria.

- Another general remark: I am not sure that this would belong into this
ID, but somewhere I would like to see an applicability statement that
underlines the differences to MANET and 6lowpan requirements and
protocols. For a reader that -- like me -- comes more from the MANET
world, it would be good to emphasize why the protocols that work well in
MANETs do not work in LLNs. MANETs are not per se limited to high power
machines and stable links but may have the same constraints as LLNs.

- Section 3.1 (Protocols Considered): This is a good new section.
However, I would add one or two explaining sentences (or references) to
the statement "This document does not consider DTN bundles [RFC5050] or
the DTN [...], because they are not routing protocols." As Thomas said,
there is no such single unique definition of what a routing protocol is.
You could either reference some document(s) with such a definition, or
explain what exact criteria does a routing protocol have and why DTN
does not meet these requirements. In particular for hierarchical NEMO,
you could argue that it *is* a routing protocol, if you consider a
definition of a routing protocol being "something that modifies the
routing table".

- Again Section 3.1: I would change the following sentence: "This
document does not seek to answer the question of whether there is any
protocol anywhere which could meet LLN application requirements.", to
"This document does not seek to answer the question of whether there is
any protocol anywhere *outside the IETF* which could meet LLN
application requirements.", i.e. add "outside the IETF"

- Section 3.2 (Criteria): Change: these criteria are "necessary but not
sufficient." to: these criteria are "necessary but not sufficient".
(move the full stop towards the end of the sentence)

- Section 4 (Suitability Summary): Personally, I would rename the
section title from "Suitability Summary" to "Evaluation Criteria" (maybe
section 3.2 Criteria should be renamed to Criteria Selection or
something similar). You reference this section from section 3.2
(Criteria) "The five criteria, presented in Section 4 [...]".
Accordingly, I would prefer to have five subsections with each criterion
as one single subsection, i.e. split up "Link and Node Cost" into two
subsections. At first, I only counted four criteria before I saw that
you combined two within one subsection.

- Section 4.2 (Table Scalability): As Thomas said, it's not only the
routing table size that should be bounded, but the complete state of a
routing protocol. For example in OLSRv2, there are many different sets
(Neighbor Set, Topology Set, Advertised Neighbors Set, ...) that are all
part of the state of a router. Otherwise, a routing protocol could
"hide" a large part of the state outside the routing table and still
fulfill the criterion of a scaled routing table.

- Section 4.4 (Control cost): I know, this has been addressed in my
prior email, but I still feel uncomfortable with this section, as it
only considers control cost and not the total cost for acquiring the
routes *and* for transmitting  data. Even if you say that generally in
LLNs the data rate is very low, still I think it would be a fairer
criterion to consider the total cost (data + control traffic). As said
by Thomas and by me, you could easily design a routing protocol with
zero-cost control cost (don't send any control traffic) but a very high
data cost (flood the whole network).

- Again Section 4.4: In my opinion, the following paragraph is
unnecessary here because it applies for all criteria, not only for
control cost:

   The control cost criterion is a necessary but not sufficient
   condition for a protocol to be a viable routing protocol for LLNs.
   Protocols not meeting this bound are unacceptable for use in this
   environment; however, there may be protocols which receive a "pass"
   for this criterion and yet are also unsuitable.

- Appendix B: In section 4.1 you mentioned that you use the formal big-O
notation. However, in the appendix you use O(R + e) and O(e) with e
being a constant. The constant should be removed from within the O().

- As said by others, a Security Considerations section would be a very
good thing to include.

Best regards,
Ulrich

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.
>
> 	Title		: Overview of Existing Routing Protocols for Low Power and Lossy Networks
> 	Author(s)	: A. Tavakoli, S. Dawson-Haggerty, P. Levis
> 	Filename	: draft-ietf-roll-protocols-survey-04.txt
> 	Pages		: 25
> 	Date		: 2009-1-21
> 	
> Networks of low power wireless devices introduce novel IP routing
>    issues.  Low-power wireless devices, such as sensors, actuators and
>    smart objects, have difficult constraints: very limited memory,
>    little processing power, and long sleep periods.  As most of these
>    devices are battery-powered, energy efficiency is critically
>    important.  Wireless link qualities can vary significantly over time,
>    requiring protocols to make agile decisions yet minimize topology
>    change energy costs.  Routing over such low power and lossy networks
>    has novel requirements that existing protocols may not address.  This
>    document provides a brief survey of the strengths and weaknesses of
>    existing protocols with respect to this class of networks.  From this
>    survey it examines whether existing and mature IETF protocols can be
>    used without modification in these networks, or whether further work
>    is necessary.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>   
> ------------------------------------------------------------------------
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jan 2009 11:10:21 +0100

---

From: JP Vasseur <[email-masked]>
Date: Sat, 24 Jan 2009 15:29:14 +0100

Hi Ulrich,

On Jan 22, 2009, at 11:26 AM, Ulrich Herberg wrote:

> - Generally, I would prefer to separate the evaluation metrics and  
> the survey of protocols according to these metrics in two different  
> same document as the choice of metrics may be influenced by the  
> choice of the protocols to be considered. Also, it would ease the  
> addition of a routing protocol later on without changing the  
> evaluation criteria.
>

As pointed out many times on this mailing list, once re-chartered for  
protocol work, we will have work on protocol specific in light of the  
application specific routing requirements documents, not the protocol  
survey (the aim of which was to see whether or not an existing routing  
protocol could be used as is).

> - Another general remark: I am not sure that this would belong into  
> this ID, but somewhere I would like to see an applicability  
> statement that underlines the differences to MANET and 6lowpan  
> requirements and protocols. For a reader that -- like me -- comes  
> more from the MANET world, it would be good to emphasize why the  
> protocols that work well in MANETs do not work in LLNs. MANETs are  
> not per se limited to high power machines and stable links but may  
> have the same constraints as LLNs.

There is no such WG item. If someone is willing to write such an  
informational document, why not but for the time being this is not  
needed. On the other hand, we may end up writing applicability  
statement to document the use of protocol X in condition Y. But again  
this is premature, we first need to complete the protocol work.

> However, I would add one or two explaining sentences (or references)  
> to the statement "This document does not consider DTN bundles  
> [RFC5050] or the DTN [...], because they are not routing protocols."  
> As Thomas said, there is no such single unique definition of what a  
> routing protocol is. You could either reference some document(s)  
> with such a definition, or explain what exact criteria does a  
> routing protocol have and why DTN does not meet these requirements.  
> In particular for hierarchical NEMO, you could argue that it *is* a  
> routing protocol, if you consider a definition of a routing protocol  
> being "something that modifies the routing table".
>

I'm not sure that we need to start a debate on what a routing protocol  
is ... at the IETF.

Thanks for the other comments, we should be able to address them in  
rev-05 (this week-end hopefully).

Thanks.

JP.

> document does not seek to answer the question of whether there is  
> any protocol anywhere which could meet LLN application  
> requirements.", to "This document does not seek to answer the  
> question of whether there is any protocol anywhere *outside the  
> IETF* which could meet LLN application requirements.", i.e. add  
> "outside the IETF"
>
> - Section 3.2 (Criteria): Change: these criteria are "necessary but  
> not sufficient." to: these criteria are "necessary but not  
> sufficient".
> section title from "Suitability Summary" to "Evaluation  
> Criteria" (maybe section 3.2 Criteria should be renamed to Criteria  
> Selection or something similar). You reference this section from  
> section 3.2 (Criteria) "The five criteria, presented in Section 4  
> [...]". Accordingly, I would prefer to have five subsections with  
> each criterion as one single subsection, i.e. split up "Link and  
> Node Cost" into two subsections. At first, I only counted four  
> criteria before I saw that you combined two within one subsection.
>
> routing table size that should be bounded, but the complete state of  
> a routing protocol. For example in OLSRv2, there are many different  
> sets (Neighbor Set, Topology Set, Advertised Neighbors Set, ...)  
> that are all part of the state of a router. Otherwise, a routing  
> protocol could "hide" a large part of the state outside the routing  
> table and still fulfill the criterion of a scaled routing table.
>
> routes *and* for transmitting  data. Even if you say that generally  
> in LLNs the data rate is very low, still I think it would be a  
> fairer criterion to consider the total cost (data + control  
> traffic). As said by Thomas and by me, you could easily design a  
> routing protocol with zero-cost control cost (don't send any control  
> traffic) but a very high data cost (flood the whole network).
>
> - Appendix B: In section 4.1 you mentioned that you use the formal  
> big-O notation. However, in the appendix you use O(R + e) and O(e)  
> with e being a constant. The constant should be removed from within  
> the O().
>
> - As said by others, a Security Considerations section would be a  
> very good thing to include.
>
> Best regards,
> Ulrich
>
>