Subject: [Roll] Fwd: Manual Post Requested for draft-ietf-roll-protocols-survey

From: Philip Levis <[email-masked]>
Date: Tue, 20 Jan 2009 11:45:13 -0800

I incorporated comments from Stephen Farrell and Thomas Clausen.  
Notably:

1) Tweaked language in abstract. Changed "mature draft" to "working  
item of an IETF WG".

2) Tweaked too strong sentence in 4 from "from analysis and  
examination" to "use" and added "unchanged" qualifier.

3) Reworded NEMO exclusion text.

4) Restructured methodology section, broke into subsections to  
delineate protocol selection from criteria. Had selection define  
positive as well as negative cases. Did not restructure exactly as  
Thomas proposed, but tried to delineate the applicability section.  
Separating protocol applicability into another section while keeping  
criteria under methodology seemed uneven.

5) Incorporated nits from Thomas: spelling, grammar, note on OLSR  
flooding, etc.

6) Made document consistent in use of the term "criterion."  Chose  
criterion over metric because metric is used in a variety of places,  
e.g., for links, and implies a measurement. In contrast, we are  
considering an analysis.

We've been in last call a long time now!!

Phil

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: January 20, 2009 11:41:03 AM PST
> To: [email-masked]
> Cc: [email-masked],[email-masked],[email-masked] 
> ,[email-masked],[email-masked]
> Subject: Manual Post Requested for draft-ietf-roll-protocols-survey
>
> Manual Posting Requested for following Internet-Draft:
>
> I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=11948
>
>
> Filename:	   draft-ietf-roll-protocols-survey
> Version:	   04
> Staging URL:	   http://www3.ietf.org/proceedings/staging/draft-ietf-roll-protocols-survey-04.txt
> Title:		   Overview of Existing Routing Protocols for Low Power and  
> Lossy Networks
> Creation_date:	   2009-01-20
> WG ID:		   roll
> Number_of_pages: 25
> Abstract:
> 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.
>
> Submitter: Philip Levis ([email-masked])
>
> Author(s):
> Philip Levis, [email-masked]
> Arsalan Tavakoli, [email-masked]
> Stephen Dawson-Haggerty, [email-masked]
>
>
>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jan 2009 11:28:45 +0100

> Posting notice follows.
> 
> I incorporated comments from Stephen Farrell and Thomas Clausen. Notably:
[...]
> 3) Reworded NEMO exclusion text.

How?

Alex

---

From: Philip Levis <[email-masked]>
Date: Wed, 21 Jan 2009 08:01:19 -0800

> Philip Levis a écrit :

I'm sorry, this was incorrect. I reworded the DTN exclusion text to  
include PROPHeT. The NEMO exclusion text remained unchanged.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jan 2009 17:22:37 +0100

> 
> On Jan 21, 2009, at 2:28 AM, Alexandru Petrescu wrote:
> 
>> Philip Levis a écrit :
>>> Posting notice follows. I incorporated comments from Stephen 
>>> Farrell and Thomas Clausen. Notably:
>> [...]

If we had ROLL requirements readable in terms similar to some Mobile IP
requirements then we could probably compare them and qualify NEMO for
ROLL, or disqualify.

For example, what are the ROLL requirements with respect to Internet
connectivity?  Is there a {urban,indus,home,building} requirement that
imposes the ROLL network to always be connected to the Internet?

Similary, I think there's no NEMO requirement [RFC4886] explicitely
imposing it to function on battery-operated devices.

In this sense - yes, NEMO exclusion should stay unchanged.

Alex

---

From: Kris Pister <[email-masked]>
Date: Wed, 21 Jan 2009 11:12:01 -0800

internet.  In fact, at this point in time most industrial environments 
intentionally have a physically separate network for their automation 
infrastructure.  This may change, but it will take a long time.

ksjp

---

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

> 1) Tweaked language in abstract. Changed "mature draft" to "working  

Good.

> examination" to "use" and added "unchanged" qualifier.

Good.

> Separating protocol applicability into another section while  
> keeping criteria under methodology seemed uneven.

Good, my proposal was just one way -- others work as well.

> 5) Incorporated nits from Thomas: spelling, grammar, note on OLSR  

Thanks.

> criterion over metric because metric is used in a variety of  
> places, e.g., for links, and implies a measurement. In contrast, we  
> are considering an analysis.

Ok, almost but not quite: there's still a lingering "requirement"  
somewhere, I think I've indicated in my latest review as well.

I still think that criterion sends the wrong message -- I understand  
that "metric" is overloaded. Can we think up another term to satisfy  
all?

> We've been in last call a long time now!!

I'm not trying purposely to be a pain, but consider this document  
important to get right, and so I try to contribute what I can. I  
should say, thought, that the authors have been quite good at quick  
turn-arounds, and deserve credit and thanks for that.

Thomas

>> Cc:  
>> [email-masked],[email-masked],[email-masked] 
>> Title:		   Overview of Existing Routing Protocols for Low Power  
>> and Lossy Networks

---

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

>> I'm sorry, this was incorrect. I reworded the DTN exclusion text  
>> to include PROPHeT. The NEMO exclusion text remained unchanged.
>

It actually calls out a good point: the survey I-D references a LOT  
of requirements docs, which are not (yet) published as RFC. Any  
thoughts as to if continued work on those requirements documents will  
in any way alter the conclusions of this I-D?

I may not have been keeping up, but where are the requirements  
documents, progress-wise, with respect to the survey I-D?

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jan 2009 13:19:15 +0100

> 
> On Jan 21, 2009, at 17:22 PM, Alexandru Petrescu wrote:
> 
>> Philip Levis a écrit :
> It actually calls out a good point: the survey I-D references a LOT of 
> requirements docs, which are not (yet) published as RFC. Any thoughts as 
> to if continued work on those requirements documents will in any way 
> alter the conclusions of this I-D?
> 

Well, if one considers that "Mobility" is mentioned at least thrice (in 
the industrial, home and building req drafts) then one doubts the 
drastic disqualification of NEMO by the protocol-survey does, at least 
beacause of the term 'Mobility' - NEMO stands for Network Mobility.

Alex

A synthesis of the reqs pulled out of the 4 ROLL reqs documents (urban, 
indus, home, building):

Requirements of Urban LLN Applications [not of routing?]:
1 Scalability: 10^2 to 10^4 sensing nodes
2 Parameter Constrained Routing: CPU, memory size, battery
3 Autonomous and Alien Configuration: 0-conf, self org topology change,
   multi-any-cast addressing, node mobility
4 Support of Highly Directed Information Flows: multiple paths towards
   the same destination
5 Support of Multicast, Anycast, and Implementation of Groupcast
6 Network Dynamicity: node association, disassociation and
   disappearance, locally optimized.
7 Latency: alert reporting solutions and to a certain extent queried
   reporting

Industrial reqs:
1 Reliability reqs: long
2 Device-aware routing reqs: battery, energy-state
3 Boradcast/Multicast: alerts to multiple servers, routers, subscribers
4 Route Establishment Time: seconds to minutes
5 Mobility: wireless worker, mobile field devices, speed 35kmph
6 Manageability: easy to deploy and manage

Unique Routing Requirements of Home Automation Applications:
1 Constraint-based Routing: CPU, memory, level of energy, sleep
   intervals, safety/convenience of changing battery
2 Support of Mobility: multi-purpose remote, mobile wearable
3 Sleeping nodes: wake-up 1 second
4 Healthcare Routing: locate new neighbor, battery, delivery of
   measurement data
5 Scalability: 250 devices
6 Convergence time: 0.5 seconds
7 Manageability: zero-conf, no human intervention
8 Stability: isolate misbehaving node

Building Automation Routing Requirements:
1 Installation: Zero-Configuration no commissioning, sleeping devices,
   local testing, device replacement
2 Scalability: area 50000-1000000 sq.ft. [4 645.152 - 92 903.04 square
   meters], 1000 routers 1000 hosts, 255 sensors, peer-to-peer
3 Mobility: mobile device association in 15s, location tracking
4 Resource Constrained Devices: power memory 10000 less than usual,
   limited processing power
5 Addressing: unicast, multicast, anycast
6 Manageability: firmware upgrades, diagnostics verbose mode, route
   tracking, path quality
7 Compatibility: IPv4, Maximum Packet Size 1526 octets
8 Route Selection: path cost, path adaptation, route redundancy, route
   discovery time 120msec, route preference, path persistence

---

From: Philip Levis <[email-masked]>
Date: Fri, 23 Jan 2009 09:11:40 -0800

>
> On Jan 20, 2009, at 20:45 PM, Philip Levis wrote:
>
>> Posting notice follows.
>>
>> 1) Tweaked language in abstract. Changed "mature draft" to  
>> "working item of an IETF WG".
>>
>
> Good.
>
>> places, e.g., for links, and implies a measurement. In contrast,  
>> we are considering an analysis.
>
> I still think that criterion sends the wrong message -- I  
> understand that "metric" is overloaded. Can we think up another  
> term to satisfy all?

I have to disagree on this one. The OED says:

criterion: a principle or standard by which something may be judged  
or decided

metric: a system or standard of measurement

We aren't measuring; we're judging whether, based on analysis and  
thought, a given protocol has a certain property. To be absolutely  
precise, one would say that the five columns are in the table are  
criteria, and the metric we use to judge them is big-O notation of  
particular properties. Does that make sense? Sorry to be such a  
stickler; I am a bit of a precision nut when it comes to English.

> turn-arounds, and deserve credit and thanks for that.

Thanks! It goes without saying (er, except I'm saying it) that your  
detailed comments on the entire document are greatly appreciated.

Phil