Subject: [Roll] Urban WSNs Requirements Feedback

From: Jonathan Hui <[email-masked]>
Date: Tue, 11 Mar 2008 22:40:57 -0700

Overall, I think this is an excellent first draft. I like how it
starts off by describing the overall operational scenario, defines the
kinds of nodes in use, the nature of the traffic (frequency, direction
of flow, etc.). Next section describes the complete use-case beginning
with deployment. It makes suggestions on what is important to the
use-case w.r.t. the routing protocol but leaves the specific
requirement statements for the requirements section.

Specific comments:

Section 2: Excellent section.

Section 3: Overall, great section. Clearly presents the use-cases
while suggesting what is important in a routing protocol to address
those use-cases. Might also want to add a section about how nodes are
phased out, if at all. That would complete the whole life-cycle.

Section 4: I'd drop "unique" from the title. Many of these
requirements are applicable to other application scenarios.

Section 4.3: IPv6 only supports a notion of multicast. The formation
of groups, in my mind, is a mechanism distinct from routing and
arguably isn't within scope of ROLL. Multicast routing is responsible
for delivering messages to two or more nodes in a group. We should
separate these two concepts.

Section 4.4: I think this is the right way to state it. Suggesting
that the traffic patterns may allow certain optimizations, but that
such optimizations aren't required.

Section 4.5: A routing protocol that operates across a variety of link
technologies in a single network is expected within ROLL. Maybe you
meant to say that the routing protocol SHOULD optimize for the
heterogeneous node capabilities. But this could also be folded into
constraint-based routing. So not sure if we need this separate from
requirement 4.2.

Section 4.6: As I mentioned with the Home Automation draft, the IP
architecture doesn't support a notion of groupcast. Maybe we should
leave such a notion to the application-layer.

Section 4.7: You might want to be a little more suggestive as to what
latencies are acceptable.

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

---

From: "Mischa Dohler" <[email-masked]>
Date: Wed, 12 Mar 2008 09:44:37 +0100

Thanks a lot, Jonathan, for this in-depth feedback! Please, see my replies
in-line. With kind regards, Mischa.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Wednesday, March 12, 2008 6:41 AM
To: [email-masked]
Subject: [Roll] Urban WSNs Requirements Feedback

Specific comments:

MISCHA: I am not sure what exactly you mean with "phased out" but I think we
catered for this with the following phrase in that section: "Differentiation
should be made between node disassociation, where the node has enough time
to inform the network about its removal, and disappearance, where the node
simply disappears without prior notification."

MISCHA: Yes, you are right. We will drop this in our next draft we will
issue with my ex-colleagues at France Telecom.

MISCHA: I totally agree with you that the organization process is distinct
from the routing problem, albeit correlated. However, since we operate on
the (energy) limit of design, we believe that the way the network is
organized and hence the way routing is facilitated should also be dealt with
in ROLL.

MISCHA: This was one of the last sections we inserted. We did this to
explicitly emphasize that heterogeneous design is a must. However, we didn't
want to go as far as to say that you need to optimize it because this
inherently means that there ought to be a strong coupling between these
heterogeneous technologies which I am not sure we can guarantee in ROLL. I
prefer to leave it as is.

MISCHA: Ok. Do you think that this section ought to be removed or could we
leave it just to make the point that this problem should be addressed?

MISCHA: Good idea: I will cross-check with my ex-colleagues in France
Telecom and also with Kris and David to get some reasonable numbers.

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 12 Mar 2008 07:39:55 -0700

Hi Mischa, thanks for the reply. See below:

> simply disappears without prior notification."

Ah, okay, so there is some statement buried in there. I still prefer 
seeing some statement that says what the expected decommissioning 
procedure is from the user's point-of-view. If that's simply to remove 
the node or battery from the node that's fine. Or is it really that the 
user/network manager needs to somehow inform the node/network that the 
node will be removed sometime soon so that the network can adapt if needed.

> organized and hence the way routing is facilitated should also be dealt with

I understand your point. I guess it wasn't clear to me what it meant for 
the routing protocol to "support the formation and identification of 
groups of field devices in the network." If the notion is that the 
routing topology should support some other protocol that is doing group 
formation, it makes it difficult to know exactly what is required until 
that protocol is formed. Note that there's a bunch of other things that 
may be required for creating such groups, including how addresses are 
assigned, the nature of such groups (can the span arbitrary nodes across 
the entire network or is there some spatial locality), while these 
things are out of scope of this specific draft they are related in that 
a routing protocol may be able to take advantage of these features. So 
I'm just looking for some clarification as to what is really intended here.

> prefer to leave it as is.

The requirement is a SHOULD so there's flexibility not to do so if you 
absolutely can't. Maybe 'optimize' is too strong a word, but say 
something along the lines of "SHOULD attempt to take advantage of 
additional resources when/where they exist" rather than "support a 
variety of different devices without compromising the operability and
energy efficiency of the network."

> leave it just to make the point that this problem should be addressed?

Well, this section also addresses multicast. So it is a good idea to 
leave it in. Also, we should stop referring to *the* routing protocol, 
since multicast and unicast may be supported by different routing 
protocols. Regarding groupcast, it might be good to state the expected 
traffic model and make some point to support it. But requiring the 
routing protocol to support groupcast directly is a bit unclear since IP 
(today) doesn't really support it.

Thanks.

---

From: "Mischa Dohler" <[email-masked]>
Date: Wed, 12 Mar 2008 16:14:18 +0100

Dear Jonathan,

Thanks for coming back on this.

I see now what you meant by "phased-out"; ok, good idea, we will add a
statement to this in our next draft. We will also address all the other
points you raised. 

I agree with you that we should start using "routing protocol(s)" instead of
"THE routing protocol".

JP, when are the next round drafts due?

Thanks and kind regards,
Mischa.

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2008 3:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Urban WSNs Requirements Feedback

Thanks.

--
Jonathan Hui

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 Mar 2008 10:17:31 -0400

Hi Jonathan,

Just a quick comment in line,

> From: Jonathan Hui <[email-masked]>
> Date: Tue, 11 Mar 2008 22:40:57 -0700
> To: <[email-masked]>

Let me shed some light here:

There two distinct aspects here:
1) The ability to address a subset of nodes: as you pointed out, today IPv6
support unicast and multicast, there is no notion of groupcast, which would
be out of the scope of ROLL indeed.

For example:

Note: with IP multicast, signaling mechanisms are used by a receiver to
join a group and the sender does not necessarily know the receivers of
the group. What is required is the ability to address a group of
receivers known by the sender even if the receivers do not need to know
that they have been grouped by the sender (since requesting each
individual node to join a multicast group would be very energy-
consuming).

Is not relevant to the routing protocol.

On the other hand,

2) You may want to have the ability to limit the scope of routing knowledge
to a subset of nodes: using levels/areas as in ISIS/OSPF or with a link
flooding scope (OSPF), ... Which is a very different requirement but clearly
a routing requirement.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 Mar 2008 10:19:10 -0400

In line,

> From: Mischa Dohler <[email-masked]>
> Organization: CTTC
> Reply-To: <[email-masked]>
> Date: Wed, 12 Mar 2008 09:44:37 +0100
> To: 'Jonathan Hui' <[email-masked]>, <[email-masked]>

Very much in line with my previous comment.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 Mar 2008 10:25:11 -0400

[snip]

> energy efficiency of the network."

I would suggest to avoid the term "optimize" in requirements documents since
it does not really mean anything unless you define the objective function,
metrics, ... Further, the support of the variety of links is a de facto
MUST, since we operate at layer 3. On the other hand, the ability to take
into account node constraints in path computation is fairly unique and he is
a MUST I guess this is what you meant to say here.

> (today) doesn't really support it.

Just make it the "routing protocol(s)"

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 Mar 2008 10:26:42 -0400

Hi Mischa,

> Date: Wed, 12 Mar 2008 16:14:18 +0100
> To: 'Jonathan Hui' <[email-masked]>
> Cc: <[email-masked]>

You're free to update to document whenever you want to (with the exception
of the period between the cut-off date and the first day of the IETF
meeting).

Thanks.

JP.