Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Philip Levis <> Thu, 17 May 2012 05:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBDE121F85A5 for <>; Wed, 16 May 2012 22:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 89QMpIhHNGC3 for <>; Wed, 16 May 2012 22:02:30 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU []) by (Postfix) with ESMTP id AC7B521F85A4 for <>; Wed, 16 May 2012 22:02:29 -0700 (PDT)
Received: from [] (helo=[]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <>) id 1SUsr5-0008AH-LD; Wed, 16 May 2012 22:02:27 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="windows-1252"
From: Philip Levis <>
In-Reply-To: <>
Date: Wed, 16 May 2012 22:02:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Thomas Heide Clausen <>
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: 0858a923cc4ba3562bb802375c61c59b
Cc: roll WG <>, Michael Richardson <>
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 May 2012 05:02:31 -0000

On May 16, 2012, at 10:11 AM, Thomas Heide Clausen wrote:

> For example: 
> 	o	the state required for storing/non-storing mode does *not* depend on a 
> 		specific implementation and deployment, but is an artifact from the RPL design.
> 	o	the message-size of RPL is not dependent on a specific implementation and deployment,
> 		but is an artifact from the RPL design.
> 	o	the use of links "upwards" based on receipt of traffic "downwards" (i.e. the unidirectional
> 		link issue) is not dependent on a specific implementation and deployment,
> 		but is an artifact from the RPL design.
> 	o	the unknown-by-source MTU issues for data-traffic when using non-storing mode 
> 		is not dependent on a specific implementation and deployment,
> 		but is an artifact from the RPL design.
> I could go on, but then it'd be easier to just paste the whole I-D into this email.


I agree that some points in the ID are valid statements about the protocol itself, such as message sizes and the issues caused by floating DODAGs. Those, to me, seem like reasonable points to make.

However, some of the points are hypotheses about performance (14), a bit naive about how wireless networks behave (13) or somewhat snippy gripes (11, 12). In my opinion, a document which focused on factual statements of the protocol design not really open to interpretation and cut hypothetical or subjective statements might be ready for the working group to consider.

As just a start, I object to 10, 11, 12, 13, and 14 being considered inherent to the protocol.

10 assumes that a node only uses DIO reception to allow a parent; the specification is pretty clear that you should check the parent is usable (section 1.1). You're taking a bad implementation decision and assuming there isn't another way to do things. 

For 11, there are implementations of RPL smaller than 50kB; they do not implement every feature, but that was kind of the point of the protocol, that it could be implemented on a sliding scale of implementation complexity. The TinyOS implementation, for example, is, I believe, ~20kB, less than half the size. You don't report what architecture the 50kB is for, clearly it would be more for a 32-bit than a 16-bit architecture. 

For 12, "implementations may exhibit a bad performance if not carefully implemented."  I think it is safe to say this is true for almost ANY protocol. A specification is not intended to be a complete statement of efficient implementation, otherwise you give little latitude to future improvements and good engineering.

For 13, this assumes that a wireless network has a stable topology which the protocol can converge to. Wireless networks are often NOT stable: one cannot expect a protocol to converge on a dynamic graph.

14 is similarly confused about what a wireless network looks like. How can the state of a distributed system based on a dynamic topology be "consistent?" I think this is a fundamental misunderstanding of how the network works.

That being said, I think point 6 is well taken and should be considered, maybe others. Maybe the constructive way to take this document, if you don't want to take the step of specifying solutions, is at least casting it as a roadmap for ways in which you think the WG should improve RPL?