Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01

Zach Shelby <zach@sensinode.com> Sat, 11 April 2009 07:07 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772513A6807 for <roll@core3.amsl.com>; Sat, 11 Apr 2009 00:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DypUT1V3qH6Z for <roll@core3.amsl.com>; Sat, 11 Apr 2009 00:06:49 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1C8D93A694D for <roll@ietf.org>; Sat, 11 Apr 2009 00:06:48 -0700 (PDT)
Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3B76ois032638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 10:06:51 +0300
Message-ID: <49E041A2.9020206@sensinode.com>
Date: Sat, 11 Apr 2009 10:07:14 +0300
From: Zach Shelby <zach@sensinode.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Richard Kelsey <richard.kelsey@ember.com>
References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <DB697165-ECA2-45B8-AD31-F44B85FC8EE6@cs.stanford.edu> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com>
In-Reply-To: <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: roll@ietf.org
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Apr 2009 07:07:24 -0000

Richard,

Richard Kelsey wrote:
>    From: Philip Levis <pal@cs.stanford.edu>
>    Date: Fri, 10 Apr 2009 06:52:04 -0700
> 
>    On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote:
> 
>    > Basically, since we have a depth, we have feasible parents (of  
>    > lesser depth) and siblings (of same depth). The draft suggests that  
>    > we can select any parent to forward on a per packet basis using the  
>    > best metric or more advanced load balancing functionality; if that  
>    > fails then we can use a sibling with some basic loop avoidance like  
>    > poison return or more advanced path vector (for hydrophiles).
> 
>    Here's a URL to a paper that describes one way to solve this problem,  
>    using the techniques I mentioned a few weeks ago and touched on in my  
>    talk in SF:
> 
>    http://sing.stanford.edu/pubs/ctp.pdf
> 
> Good stuff.  Relating this back to the Routing Fundamentals
> draft, it seems clear that ROLL will most likely use trees
> for at least some routing, and while Router Advertisements
> can be used to build trees, it will be good if tree
> building and/or maintenance can be performed independently
> of Router Advertisements.  They add too much overhead
> to make it easy to react quickly to changing conditions.

Don't think of router advertisements as overhead - as we are working 
with IP networks you will always have RAs as they are an integral part 
of network bootstrapping and maintenance (Neighbor Discovery). As you 
have RAs anyways, you might as well piggyback some tree information. 
Trickle can also be used to optimize the RA traffic to an appropriate 
level.

The same can be said about other ND traffic in these networks such as 
NS/NAs (IPv6), or RR/RCs (in 6LoWPAN). If you have the ND traffic 
anyways, piggybacking is good.

That said, I do see the need for carrying metric information (as done in 
the CTP protocol Phil is referencing) in data traffic (using an IPv6 
hop-by-hop option) especially for very dynamic networks. I had this in 
mind when we wrote the Routing Fundamentals draft as an option. From my 
practical experience it is useful, and only needs to be applied to 1-10% 
of data packets depending on how dynamic the network is.

- Zach


>                                    -Richard Kelsey
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

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.