Subject: [6lowpan] Fundamental concerns about 6lowpan ND

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 13 Oct 2009 09:50:49 +0200

----- Message transféré ----
De : Julien Abeillé <[email-masked]>
À : [email-masked]
Envoyé le : Mar 13 Octobre 2009, 9 h 40 min 17 s
Objet : Re: [6lowpan] Fundamental concerns about 6lowpan ND

Hi Carsten,

On Mon, 2009-10-12 at
 21:13 +0200, Carsten Bormann wrote:
> Sure it would be nice if that "just worked", but it doesn't.

As far as I see, among the procedures defined in 4861 (address resolution, NUD, router discovery, prefix discovery, redirect, next hop determination, parameter discovery, next hop determination, DAD)
ony DAD fails. Just do proxy ND on each lowpan node and this is solved.

regarding the assumptions that you do not know whether your neighbors are sleepy and will receive an IP packet (this is the underlying assumption about failure of NS.., end of 1.2)
- RPL will break with this assupmtion (many protocols will)
- why do you though garantee that unicast will not?
- for NUD, you assume that you will be able to reach the white board although you assume you typically do not know when your neighbors are awake
- if you cannot garantee that your neighbors are awake, how do you reach the white board?
- once you confirmed reachability of a neigbor through white board, how do you know your app will manage to wake him up?

for me this assumption does not hold. Wise MAC like or centralized (e.g. TSMP) layer 2 have been able to provide very high reliability and very low duty cycle for years in real deployments.

In these environments as I said 95% of 4861 ND works, only DAD fails and can be fixed trivialy.

Best,
Julien

---

From: Mikko Saarnivala <[email-masked]>
Date: Tue, 13 Oct 2009 11:08:35 +0300

Mathilde, Julien, All,

The ietf mail server is experiencing some problems and I'm quite sure 
which part of the quoted email is written by whom - sorry about that.

Mathilde Durvy (mdurvy) wrote:
> *De :* Julien Abeillé <[email-masked]>
> *À :* [email-masked]
> *Envoyé le :* Mar 13 Octobre 2009, 9 h 40 min 17 s
> *Objet :* Re: [6lowpan] Fundamental concerns about 6lowpan ND
> 
> Hi Carsten,
> 
> On Mon, 2009-10-12 at
> As far as I see, among the procedures defined in 4861 (address 
> resolution, NUD, router discovery, prefix discovery, redirect, next hop 
> determination, parameter discovery, next hop determination, DAD)

Sorry Mathilde but we don't want to do _more_ on each node - these 
devices are often times very resource limited and although adding 
proxy-nd and full 4861 ND might sometimes be possible it quite often is 
not. In the end we would end up having more flavors of 6lowpan, more 
options, more cost per device and more _interoperability problems_.

The 6lowpan-nd is currently extremely simplistic, it can be implemented 
in a very compact space and thus enables smaller (i.e. more) devices to 
be IP enabled.

Best regards,

-- 
Mikko Saarnivala
CTO
Sensinode Ltd.
Hallituskatu 13-17 D
90100 OULU
FINLAND

tel: +358 10 387 8686
mobile: +358 50 569 6287
email: mikko.saarnivala[a]sensinode.com
home: www.sensinode.com

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Oct 2009 14:52:54 +0200

Hi Carsten,

On Mon, 2009-10-12 at

<Pascal>

Probably the main reason why the group went for the white board model
was to avoid flooding over a potentially large network of potentially
very battery-constrained nodes. 

Also I wouldn't simply proxy ND recursively without any structuring. If
you could, there'd be no need for routing protocols or spanning tree and
all that sort of things. You'll note that 6LoWPAN ND has only one
backbone so the hierarchy for proxy ND is clear and loopless. Same goes
for WIFI ESS. 

Within the LoWPAN we certainly do not proxy ND and we require a real
routing protocol such as RPL within an edge LoWPAN or something
OLSR/OSPF for a more core network such as FR/ATM.

</Pascal>

regarding the assumptions that you do not know whether your neighbors
are sleepy and will receive an IP packet (this is the underlying
assumption about failure of NS.., end of 1.2)
- RPL will break with this assupmtion (many protocols will)
- why do you though garantee that unicast will not?
- for NUD, you assume that you will be able to reach the white board
although you assume you typically do not know when your neighbors are
awake
- if you cannot garantee that your neighbors are awake, how do you reach
the white board?

<Pascal>

Synchronizing with one neighbor to forward unicast is a lot easier and
economical than having to wake up all neighbors just to have them repeat
multicast queries that no one is interested in. Some link layers
synchronize time slots, while others use a preamble to wait for the
next-hop to wake up. From L3, either way is certainly fine. What we care
is for the operational cost on resources, in particular battery. And
multicast is not your friend. Basically, we must avoid by design any
situation where a node has to wake up just to listen to a packet and
then drop it because it is not concerned after all.

</Pascal>

- once you confirmed reachability of a neigbor through white board, how
do you know your app will manage to wake him up?

for me this assumption does not hold. Wise MAC like or centralized (e.g.
TSMP) layer 2 have been able to provide very high reliability and very
low duty cycle for years in real deployments.

In these environments as I said 95% of 4861 ND works, only DAD fails and
can be fixed trivialy.

<Pascal>

Wrong problem though. The problem is NOT to reuse 4861 at all cost. The
problem is to find an ND solution for non-transitive links that fits
within power and implementation size constraints, supports mobility
(inherent to radio transmissions even for fixed nodes) and scales to the
thousands over the said non-transitive links within the said power
constraints.

I am not in favor of adding an RFC 4861 solution that works only in
specific configurations, and fits none of the requirements above. This
can only increase the implementation cost and confuse the market. We
discussed that at the meeting in Dublin and the approach that was
followed since then is the one that got the WG consensus.

What I think we agree upon though, is that the ND solution for 6LoWPAN
should be one of  much larger applicability than say, 802.15.4 for which
the WG was initially created.  The authors spent considerable efforts
just to make it so and we think that the proposed approach is fit for
non-transitive links in a way more general fashion. I think that we
should concentrate our efforts in that direction, rather than looking
behind at RFC 4861.

</Pascal>

Cheers,

Pascal

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 13 Oct 2009 16:33:00 +0200

Hi all,
 
summarizing my thoughts:
1 about sleepy nodes
MAC layer approaches such as sampled listening (wise MAC...) or
centralized (TSMP...) ensure that packets are received, multicasts or
unicasts, if they need to, with very low duty cycles (~0.1%).
If we assume that packets are very frequently lost (at IP layer) because
nodes are sleeping, then most IP protocols will break.
If we assume this only for multicasts, RPL for instance will have
trouble
If we assume this also for unicasts, there will be problems to reach the
white board for NUD. Then if we manage to reach it, the application will
have trouble to reach the neighbor. 
 
2 about the superiority of a unicast approach compared to a multicast
one with regards to power consumption (expressed in terms of nodes
needing to wake up)
- sample network topology 1 (L2):
5 hops tree (2 childs per parent), 1+2+4+8+16+32 nodes. average number
of neighbors is around 3. average number of hops to sink is around 4.
multicast NS needs 4 nodes awake (1 sender + 3 receivers) for one packet
transmission
unicast NS needs 2 nodes awake for 4 packet transmissions = 8
Hence it seems that in this topology (one of the target scenarios i
guess), multicast uses less power than unicast
- generally the number of nodes that need to wake up for a mcast NS is 1
+ average number of neighbors
  number of nodes that need to wake up for unicast is 2 x average number
of hops
There are probably topolgies where the unicast is superior, but in the
general case it is not clear.
Am I missing something?
 
3 about changing ND for specific links
- It is clearly acceptable in the general case (Carsten quotes from
4861). It does not mean that it is a must, and reusability is clearly
also an advantage. hence I am ok to revise ND if there is a clear need
(see below why I think there is not except for DAD)
- RFC3122 (inverse ND) is an extension to ND, not a redesign
 
4 about layer 3 addresses and layer 2
I do not think it is reasonable to allow disabling address resolution (I
know nd-06 is more flexible). I think it should be mandatory for all
nodes to do address resolution. If the L2 address is deducted from L3,
what is the use of a L2 address? The layering is not respected, and i do
not think there are enough reasons to do so. 
 
5 what needs to be fixed in my opinion
considering 1 and 2, non transitivity is the only issue I am convinced
about with 15.4. I guess only DAD needs to be fixed in these
environments with possible changes to ND. the rest should remain
optional in my opinion, or be part of an ND update/deprecation in 6man
 
Best,
Julien

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pascal Thubert (pthubert)
	Sent: mardi 13 octobre 2009 14:53
	To: Mathilde Durvy (mdurvy); 6lowpan
	Cc: Patrick Wetterwald (pwetterw)
	Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND

	Hi Carsten,

	On Mon, 2009-10-12 at

	As far as I see, among the procedures defined in 4861 (address
resolution, NUD, router discovery, prefix discovery, redirect, next hop
determination, parameter discovery, next hop determination, DAD)
	ony DAD fails. Just do proxy ND on each lowpan node and this is
solved.

	<Pascal>

	Probably the main reason why the group went for the white board
model was to avoid flooding over a potentially large network of
potentially very battery-constrained nodes. 

	Also I wouldn't simply proxy ND recursively without any
structuring. If you could, there'd be no need for routing protocols or
spanning tree and all that sort of things. You'll note that 6LoWPAN ND
has only one backbone so the hierarchy for proxy ND is clear and
loopless. Same goes for WIFI ESS. 

	Within the LoWPAN we certainly do not proxy ND and we require a
real routing protocol such as RPL within an edge LoWPAN or something
OLSR/OSPF for a more core network such as FR/ATM.

	</Pascal>

	regarding the assumptions that you do not know whether your
neighbors are sleepy and will receive an IP packet (this is the
underlying assumption about failure of NS.., end of 1.2)
	- RPL will break with this assupmtion (many protocols will)
	- why do you though garantee that unicast will not?
	- for NUD, you assume that you will be able to reach the white
board although you assume you typically do not know when your neighbors
are awake
	- if you cannot garantee that your neighbors are awake, how do
you reach the white board?

	<Pascal>

	Synchronizing with one neighbor to forward unicast is a lot
easier and economical than having to wake up all neighbors just to have
them repeat multicast queries that no one is interested in. Some link
layers synchronize time slots, while others use a preamble to wait for
the next-hop to wake up. From L3, either way is certainly fine. What we
care is for the operational cost on resources, in particular battery.
And multicast is not your friend. Basically, we must avoid by design any
situation where a node has to wake up just to listen to a packet and
then drop it because it is not concerned after all.

	</Pascal>

	- once you confirmed reachability of a neigbor through white
board, how do you know your app will manage to wake him up?
	
	for me this assumption does not hold. Wise MAC like or
centralized (e.g. TSMP) layer 2 have been able to provide very high
reliability and very low duty cycle for years in real deployments.
	
	In these environments as I said 95% of 4861 ND works, only DAD
fails and can be fixed trivialy.

	<Pascal>

	Wrong problem though. The problem is NOT to reuse 4861 at all
cost. The problem is to find an ND solution for non-transitive links
that fits within power and implementation size constraints, supports
mobility (inherent to radio transmissions even for fixed nodes) and
scales to the thousands over the said non-transitive links within the
said power constraints.

	I am not in favor of adding an RFC 4861 solution that works only
in specific configurations, and fits none of the requirements above.
This can only increase the implementation cost and confuse the market.
We discussed that at the meeting in Dublin and the approach that was
followed since then is the one that got the WG consensus.

	What I think we agree upon though, is that the ND solution for
6LoWPAN should be one of  much larger applicability than say, 802.15.4
for which the WG was initially created.  The authors spent considerable
efforts just to make it so and we think that the proposed approach is
fit for non-transitive links in a way more general fashion. I think that
we should concentrate our efforts in that direction, rather than looking
behind at RFC 4861.

	</Pascal>

	Cheers,

	Pascal