Subject: [RSN] Re: Routing in L2N presentation file

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Aug 2007 15:46:20 -0400

Hi Ved,

On Jul 25, 2007, at 10:59 AM, Ved Kafle wrote:

> Hi JP,
>
> Is it possible to get the presentation file you used in the routing  
> area
> meeting?
> I could find it on the web.
>

I was about to do so, here it is: 

We'll soon have a Web Page to point to for RSN related work.

Thanks.

JP.

> Ved Kafle

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: [email-masked]
Date: Tue, 7 Aug 2007 07:47:19 -0500 (CDT)

Please do not send a 3.9 MB file as attachment to a whole group when
actually a single person requested it. It blocks the inbox suddenly.

Natarajan Meghanathan

---

From: JP Vasseur <[email-masked]>
Date: Tue, 7 Aug 2007 09:20:41 -0400

sorry for the inconvenience, it had actually been requested by quite
a few people ...

---

From: Kris Pister <[email-masked]>
Date: Fri, 10 Aug 2007 10:47:11 -0700

JP - great presentation.   I hope that it was well received.  I'm very 
supportive of everything in that document, with one exception.  There is 
one assumption that I believe is potentially fatal to the entire 
6lowpan/rsn effort in ietf.  On slide 11 you state "Research has focused 
on near-optimal solutions to specific problems", and then in bold "IP is 
maximizing interoperability, not aiming at finding a local optimum 
;-)".  I agree with the second statement, but the first one is flat out 
wrong.
Very few people in sensor network research seem to care about 
near-optimal solutions.  Consider one of the best-received papers 
[Kim07] at the recent IPSN conference.  Note that the authors are 
leaders in the field, this is a respected conference, one of the better 
papers, and this is the dissertation work culminating four years of 
research on this project.  The paper presents the best academic work to 
date on reliable multi-hop data collection, MP2P.  The payload goodput 
in this network was 1.4% of the channel bandwidth, at 100% radio duty 
cycle.  This is not "near-optimal" in any sense that I know.

If we start with 1.4%, and then degrade that so that we can maximize 
interoperability, we'll be left with something that no one will use.  We 
have an opportunity to do this right - let's not fall victim to the 
Zigbee-esque assumption that all we need to do is define *something* and 
adoption will be automatic.

ksjp

[Kim07] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health 
Monitoring of Civil Infrastructures Using Wireless Sensor Networks", IPSN07.

JP Vasseur wrote:
>> Is it possible to get the presentation file you used in the routing area
>> meeting?
> ------------------------------------------------------------------------
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 10 Aug 2007 11:12:00 -0700

On Aug 10, 2007, at 10:47 AM, Kris Pister wrote:

> JP - great presentation.   I hope that it was well received.  I'm  
> very supportive of everything in that document, with one  
> exception.  There is one assumption that I believe is potentially  
> fatal to the entire 6lowpan/rsn effort in ietf.  On slide 11 you  
> state "Research has focused on near-optimal solutions to specific  
> problems", and then in bold "IP is maximizing interoperability, not  
> aiming at finding a local optimum ;-)".  I agree with the second  
> statement, but the first one is flat out wrong.
> Very few people in sensor network research seem to care about near- 
> optimal solutions.  Consider one of the best-received papers  
> leaders in the field, this is a respected conference, one of the  
> better papers, and this is the dissertation work culminating four  
> years of research on this project.  The paper presents the best  
> academic work to date on reliable multi-hop data collection, MP2P.   
> The payload goodput in this network was 1.4% of the channel  
> bandwidth, at 100% radio duty cycle.  This is not "near-optimal" in  
> any sense that I know.
>
> If we start with 1.4%, and then degrade that so that we can  
> maximize interoperability, we'll be left with something that no one  
> will use.  We have an opportunity to do this right - let's not fall  
> victim to the Zigbee-esque assumption that all we need to do is  
> define *something* and adoption will be automatic.
>
> ksjp
>

You're right, Kris, but it's a bit deeper than that. There's a big  
debate in the research community right now about layered vs. cross- 
layer design, and there are more of the latter than the former. The  
protocol briefly mentioned in the paper you cite has a full paper  
about it that will be appearing in SenSys. It's clear that a cross- 
layer design could lead to higher performance (hence JP's comment  
about optimal point solutions), and some reviewers made this point.  
But you can't easily compose cross-layer protocols into larger  
systems. hence the morass many research systems enter when they try  
to incorporate protocols X, Y, and Z together. So the community is  
slowly shifting from "how good can we get if we throw out all  
layering" and moving towards "what have we learned from that and how  
can we apply it to the layers?" That shift is one reason why R2LN's  
timing is very auspicious.

The 1.4% is a bit misleading. As 6.2 discusses, the transport  
protocol in the paper achieves 94.8% of the layer 3 protocol's  
throughput (when considering the 1/3rd effect you get from multihop).  
The big inefficiencies are the layer 3 and 2 protocols the particular  
implementation builds on, neither of which were optimized for  
throughput. It would be great to see how well the e2e transport  
protocol works on top of a layer 2 and a layer 3 with this metric in  
mind.

Phil

---

From: Kris Pister <[email-masked]>
Date: Fri, 10 Aug 2007 17:08:11 -0700

>> throughput (when considering the 1/3rd effect you get from multihop).

Phil - this is exactly the sort of thing that drives me nuts about 
papers in this community.  First off, section 6.2 discusses details of 
single-hop transmission using a 14.4kbps radio, and claims 33% 
efficiency.  The actual deployment is multi-hop, and uses 250kbps 
radios, and achieves 1.4%.
The "1/3rd effect" that you allude to is a constraint imposed by 
single-channel operation.  If you use a channel-hopping protocol the 
theoretical limit is 1, not 1/3.
Try telling an end user that his measured 1.4% throughput is misleading, 
and that he should really take into account all of the artificial 
constraints that you have come up with to explain it.

ksjp

Philip Levis wrote:
>> very supportive of everything in that document, with one exception.  
>> There is one assumption that I believe is potentially fatal to the 
>> entire 6lowpan/rsn effort in ietf.  On slide 11 you state "Research 
>> has focused on near-optimal solutions to specific problems", and then 
>> in bold "IP is maximizing interoperability, not aiming at finding a 
>> local optimum ;-)".  I agree with the second statement, but the first 
>> one is flat out wrong.
>> interoperability, we'll be left with something that no one will use.  
>> We have an opportunity to do this right - let's not fall victim to 
>> the Zigbee-esque assumption that all we need to do is define 
>> *something* and adoption will be automatic.
>>
>> ksjp
>>
> debate in the research community right now about layered vs. 
> cross-layer design, and there are more of the latter than the former. 
> The protocol briefly mentioned in the paper you cite has a full paper 
> about it that will be appearing in SenSys. It's clear that a 
> cross-layer design could lead to higher performance (hence JP's 
> comment about optimal point solutions), and some reviewers made this 
> point. But you can't easily compose cross-layer protocols into larger 
> systems. hence the morass many research systems enter when they try to 
> incorporate protocols X, Y, and Z together. So the community is slowly 
> shifting from "how good can we get if we throw out all layering" and 
> moving towards "what have we learned from that and how can we apply it 
> to the layers?" That shift is one reason why R2LN's timing is very 
> auspicious.
>
> The 1.4% is a bit misleading. As 6.2 discusses, the transport protocol 
> in the paper achieves 94.8% of the layer 3 protocol's throughput (when 
> considering the 1/3rd effect you get from multihop). The big 
> inefficiencies are the layer 3 and 2 protocols the particular

---

From: Philip Levis <[email-masked]>
Date: Fri, 10 Aug 2007 17:16:08 -0700

On Aug 10, 2007, at 5:08 PM, Kris Pister wrote:

> papers in this community.  First off, section 6.2 discusses details  
> of single-hop transmission using a 14.4kbps radio, and claims 33%  

:)

> single-channel operation.  If you use a channel-hopping protocol  
> the theoretical limit is 1, not 1/3.

Absolutely -- it's the 1/3 imposed by having a single-channel CSMA.

> Try telling an end user that his measured 1.4% throughput is  
> misleading, and that he should really take into account all of the  
> artificial constraints that you have come up with to explain it.

Agreed -- from a complete system standpoint, 1.4% is 1.4%. The TinyOS  
15.4 MAC is notoriously inefficient for throughput, as it uses really  
big backoff interval. All I was trying to say is that if you improved  
the MAC in this regard, then the protocol described there would  
benefit from it. We should be focusing on optimizing individual  
layers, as they benefit everything above and below, rather than just  
exploring cross-layer approaches. Of course, as I said earlier, cross- 
layer efforts have helped figure out *what* those layers need: your  
comments a few months ago about schedule information is a great  
example. This is one reason I think 6lowpan has real potential to  
shake out the space and lead to technical excellence.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 14 Aug 2007 09:29:09 -0400

Hi Kris,

On Aug 10, 2007, at 1:47 PM, Kris Pister wrote:

> very supportive of everything in that document,

Thanks.

> with one exception.

Ah ;-)

> has focused on near-optimal solutions to specific problems", and  
> then in bold "IP is maximizing interoperability, not aiming at  
> finding a local optimum ;-)".  I agree with the second statement,  
> but the first one is flat out wrong.
> optimal solutions.

OK let me first clarify something: first the statement was not  
negative by all means but having reviewed quite a few
paper on WSN, there is a plethora of papers the aim of which is  
indeed to find a near-optimal solutions to a very
specific problem. But you're right that this is not a generality. But  
more importantly the point that I was trying to stress
is the following: the space of Sensor Networks or L2Ns to be a bit  
more generic is highly fragmented and the set of
issues and constraints can vary significantly from one application to  
another. Thus, trying to find a near optimal to
any specific problem would unavoidably lead to either N solutions  
(which we want to avoid !). And indeed, one of the
greatest thing about IP is interoperability.

I heard many people in the past telling me that they HAD to define a  
proprietary solution to get something optimal
for a specific environment. Not only this is quite arguable, but our  
goal is to define a common set of IP-based solutions
that would address most of the problem space (not all, sorry).

> Consider one of the best-received papers [Kim07] at the recent IPSN  
> conference.  Note that the authors are leaders in the field, this  
> is a respected conference, one of the better papers, and this is  
> the dissertation work culminating four years of research on this  
> project.  The paper presents the best academic work to date on  
> reliable multi-hop data collection, MP2P.  The payload goodput in  
> this network was 1.4% of the channel bandwidth, at 100% radio duty  

Note that I did not say that interoperability implied sub-sub- 
optimality ;-) but I guess that I clarified my statement.

Thanks for your support.

JP.