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

Axel Colin de Verdiere <axel-ietf@axelcdv.com> Wed, 16 May 2012 23:46 UTC

Return-Path: <axel-ietf@axelcdv.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E089E8027 for <roll@ietfa.amsl.com>; Wed, 16 May 2012 16:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFQO79eluuHL for <roll@ietfa.amsl.com>; Wed, 16 May 2012 16:46:00 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 47A7A9E8020 for <roll@ietf.org>; Wed, 16 May 2012 16:46:00 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D1C4E557FED for <roll@ietf.org>; Wed, 16 May 2012 16:45:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4500C1C08C5; Wed, 16 May 2012 16:45:59 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.1.107] (Cs-136-215.CS.UCLA.EDU [131.179.136.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CFD3C1C0105; Wed, 16 May 2012 16:45:58 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Axel Colin de Verdiere <axel-ietf@axelcdv.com>
In-Reply-To: <04348A3C-F9EC-4427-AC44-17600405331C@watteco.com>
Date: Wed, 16 May 2012 16:44:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4944ECBE-792F-4B88-815B-0867E8532F35@axelcdv.com>
References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <B1B81482-0F7E-4BCE-BBA7-B21949E3C16C@cisco.com> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> <A21F1E68-B703-48BC-A03C-C00EC01A01D9@thomasclausen.org> <04348A3C-F9EC-4427-AC44-17600405331C@watteco.com>
To: C Chauvenet <c.chauvenet@watteco.com>
X-Mailer: Apple Mail (2.1084)
Cc: roll WG <roll@ietf.org>, Michael Richardson <mcr@sandelman.ca>
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 16 May 2012 23:46:01 -0000

Dear Cedric,

On May 16, 2012, at 3:28 PM, C Chauvenet wrote:

> Thomas, 
> 
> Le 16 mai 2012 à 19:37, Thomas Heide Clausen a écrit :
> 
>> Dear Cedric,
>> 
>> On May 16, 2012, at 18:48 , C Chauvenet wrote:
>> 
>>> Thomas,
>>> See inline,  
>>> 
>>> Le 16 mai 2012 à 17:08, Thomas Heide Clausen a écrit :
>>> 
>>>> Dear Cedric,
>>>> 
>>>> Thank you for your email. Comments below.
>>>> 
>>>> On 16 May 2012, at 16:13, C Chauvenet <c.chauvenet@watteco.com> wrote:
>>>> 
>>>>> Hi, 
>>>>> 
>>>>> I definitely agree that implementation feedback is always good to know, so your experiences are welcomed.
>>>>> 
>>>>> I also think that problems investigations need a complete and exact view, so I would encourage you to put much more details about the scenario and the environment where you experimentations took place.
>>>>> For instance, I would enjoy a "RPL Implementation Description" section in you draft listing the hardware your used, your RPL parameters, the RPL drafts and mechanisms implemented, your OS etc...
>>>> 
>>>> As I indicated to JP already:
>>>> 
>>>> 1) 	this draft is not "just" based on a single scenario, environment or implementation 
>>>> 	(and, therefore, not "just" based on a single test). 
>>> 
>>> Does it means that your run multiple scenarios ? 
>>> That would be great.
>>> 
>> 
>> As indicated elsewhere, yes. Although its details are immaterial to this discussion,
>> 
>>>> 
>>>> 2) 	the observations that we made during the test_S_ served to make us look at the RPL
>>>> 	RFC again, to explain our observations and to generalize them from the written word
>>>> 	of that RFC.
>>>> 
>>>> Therefore, I do not think that any such description would bring anything (other than entropy and delay) to the process. The RPL RFC and this I-D is more than sufficient.
>>>> 
>>>> As to what features were implemented, that is easy to answer: the RPL RFC (except for security) to the letter and with the parameters suggested there, and OF0. However, even the parameters are immaterial for the observations listed in this I-D.
>>> 
>>> I think we are progressing on the definition of your RPL implementation : could you also precise what part of the RPL spec you have implemented ? eg. What mode of Operation and why, what options did you choose to include in DIO messages, your metrics ....
>>> 
>> 
>> 1) 	All the relevant details are included in the I-D
>> 2)	Again, the observations in that I-D can be made from looking (now that we know what to look for)
>> 	in the RPL RFC
>> 3)	The experiments only served to help us see "what to look for" in the RPL RFC.
>> 4)	See also email that I recently sent to JP.
>> 
>>>> 
>>>>> If I read a paper with orthogonal observations with the same level of details as in your draft, then how could I forge my opinion ?
>>>> 
>>>> I'd suggest reading the indicated parts of the RPL RFC conjointly with this I-D. Again, the observations that we present in this I-D make exclusive reference to RPL, and not to a specific implementation or deployment.
>>>> 
>>>>> Looking at this draft, it seems that it gathers lots of previous discussions that occurred during the past year on various mailing lists, and IETF meetings.
>>>>> 
>>>>> Does your experimentations takes care about these recommendations ?
>>>> 
>>>> Again, the issues raised in this I-D are based on what can be observed from the RPL RFC. 
>>>> 
>>>> If there are additional considerations required (which you seem to indicate to be the case) which are not reflected in the RPL RFC, in order to overcome the issues raised, then that indeed should be a big problem for the IETF and for ROLL....
>>> 
>>> These recommendations were for the problems you pointed out in *Your* implementation.
>>> Of course if other implementers are facing to the same problems, they could rely on it, but I have not heard about similar problems outside your lab from now.
>> 
>> These are not implementation problems, these are artifacts from the RPL RFC design choices.
>> 
>>>> 
>>>>> If not, does your draft mention the propositions that have been made to address the problems you point out in your draft ?
>>>>> I think it could be worth to leverage on these previous discussions.
>>>> 
>>>> I firmly disagree. The IETF and ROLL has published an RFC - that's what this I-D discusses. 
>>>> 
>>>> Discussing what may have been proposed in other media would be entirely out of scope.
>>> 
>>> Again, this is not related to the RPL RFC but *your* implementation that received some guidance regarding its problems.
>>> The RPL RFC should not include tips for your implementation, but your implementation and your draft should pay attention to the tips given to you.
>>> 
>> 
>> This has nothing to do with "tips for [my] implementation whatsoever. See examples I gave in reply to JP.
>> 
>> 
>>>> 
>>>>> Your draft is a list of Description and Observations.
>>>>> Maybe you could add a "Resolution Proposal" section for each problem, gathering previous discussion and your own proposals ?
>>>> 
>>>> Nope. That's not the objective of this I-D.
>>> 
>>> That's too bad, this is what all readers of this draft are looking for !
>> 
>> It would be great to have that, so please write such a draft, addressing the issues that this I-D has presented.
> 
> Mukul seems to work on it.
> I guess a good mail browser could do a big part of the job.
> 
>> 
>> I am personally a great fan also of interoperability reports (something which ROLL doesn't have either and which is not the point of this I-D either)
> 
> Me too.
> The only "public" interop event I remember took place during IETF 77 in March 2010.
> 5 differents companies were able to form a single DODAG using an early version of the RPL specification.
> Of course the intend of this event was not to do an exhaustive test of the RPL mechanisms but prove that the core design is correctly working.
> This is not surprising, given that some mechanisms used in RPL are used in numerous commercial solution for a while.
> You should also have knowledge about the great effort of the Zigbee Alliance who is running interop events very regularly.
> RPL is the default routing protocol of the future Zigbee IP stack, and some details have been given by robert craigie at the LWIG session of last IETF.
> Do you seriously think that these interop events occuring every 2 or 3 months and involving most of the major companies in WSN would not have detect if something were wrong with the RPL design ?

I would still hope that RPL works for Zigbee since they list it in their protocol stack, but their interop events do not help much here since they don't give any public feedback. Furthermore, the only details given at the LWIG session were that Zigbee uses RPL in non-storing mode, and that some features had to be turned off (at least from what I can infer from the presentation and the minutes). As an implementer, I would need a little bit more detail to know whether (and how) RPL would work for my application. And even if I were to trust them blindly, what if I wanted to use RPL in non-storing mode?

> If you think that you are not able to figure out yourself the problems you see in RPL, go buy some commercial solutions ;-)

I might be relatively new here, but I wasn't aware the IETF relied on commercial solutions to fix its standard track protocols...


Axel


> 
> 
>> 
>>> Without offense, saying "this is bad" without a better proposition seems like half-work ! 
>>> And this is true for most of the discussion topics in life, far away from RPL !
>> 
>>> 
>>>> I would venture that if the WG is serious about applicability statements, then those applicability statements would be the place for discussion of "how this issue, raised in this I-D, is addressed or moot for a given deployment".
>>>> 
>>>>> Identifying what is wrong in your implementation
>>>> 
>>>> Considering that these observations are not implementation-specific, but are directly on the RPL RFC, I venture the observations that there's nothing "wrong in my implementation" here.
>>>> 
>>> 
>>> As a general comment : RPL is a routing protocol targeted for a very wide application area. 
>>> Some may think this is good because it covers a lot of needs.
>>> Some may think it is bad because it is wide and not specific enough for their application.
>>> Wathever your position, these two arguments are valid, this is all a matter of viewpoint and tradeoff.
>> 
>> I disagree here, Cedric, but this thread is not the place for that particular discussion.
> 
> I cannot see how you could not be inline with these statement, but anyway let's get back in the arena.
> 
>>> So, because RPL is wide enough for multiple application, you have to take some time to tune it correctly, according to your application.
>> 
>> I disagree here, Cedric, but this thread is not the place for that particular discussion. This I-D does *not* discuss a specific application or deployment, but merely reflects on RPL, as published by the ROLL working group.
>> 
>>> One simple choice that every RPL implementers will ave to answer is : Use Storing or Non Storing Mode ? This is a fondamental design choice that cannot be made outside a scenario consideration.
>> 
>> I agree here.
>> 
>> And, this I-D provides some observations - for example about storage requirements, and about requirements for all RPL routers in (for example, for storing node) the case that the DODAG root can fail and floating DODAGs created.
>> 
>> This has nothing to do with a specific implementation, deployment, experiment, scenario or application, but is an artifact of a fundamental design choice made in RPL.
> 
> This argument relies for more than a year on a research paper that is not inline with your statement, as discussed with the authors during IETF events.
> The memory available to store routes simply relates to the memory available in your mote, and this is directly given by the hardware you use.
> So the routing table size is more linked to the hardware than linked to the RPL mechanisms.
> If you need more routing entries, buy a hardware with more memory, or optimize the way you store routing entries.
> Is this problem really an "artifact of a fundamental choice made in RPL" or a generic routing protocol problem ?
> I guess Mukul will give some thoughts on this point, as It has been already discussed.
> 
> Cédric.
> 
>> 
>>> Be sure that there is no magic RPL tuning that works for all, but multiple fine RPL tuning for multiple applications.
>>> I honestly cannot believe in generic results given the incredibly variety of tuning that RPL can have.
>> 
>> This is, again, not a matter of "tuning of parameters" at all. That's not what the I-D describes, or aims at describing.
>> 
>>> So my final position is that we disagree on the need of more details in your experiments.
>> 
>> I'm afraid that I disagree for this I-D. That's not the point of it, and I think that it is fairly clear in the I-D that it's not (as well as it is clear what the point is, and what the goals are for it)
>> 
>> I think that it would be interesting to have another I-D describe parameter tunings etc for a given application. I would expect that to be part of what the applicability statements were supposed to do. It's, however, still not in this I-D that it should be done.
>> 
>> Thomas
>> 
>>> Cédric.
>>> 
>>>> Thomas
>>>> 
>>>> 
>>>>> is a good first step, but the hardest part is to propose some corrections.
>>>>> Best Regards,
>>>>> 
>>>>> Cédric Chauvenet.
>>>>> 
>>>>> Le 16 mai 2012 à 15:04, JP Vasseur a écrit :
>>>>> 
>>>>>> Dear Thomas,
>>>>>> 
>>>>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote:
>>>>>> 
>>>>>>> Dear JP and Michael,
>>>>>>> 
>>>>>>> Thank you for your mail.
>>>>>>> 
>>>>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote:
>>>>>>> 
>>>>>>>> Dear Thomas,
>>>>>>>> 
>>>>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote:
>>>>>>>> 
>>>>>>>>> Dear JP, Michael, all
>>>>>>>>> 
>>>>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and discussed at the Paris meeting.
>>>>>>>>> 
>>>>>>>>> The authors consider the document complete and "done", and are looking to take it forward in the IETF 
>>>>>>>>> process for publication as "Informational RFC" in the very near future. 
>>>>>>>>> 
>>>>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is willing to accept and progress this 
>>>>>>>>> document towards publication?
>>>>>>>> 
>>>>>>>> Thanks for your suggestion. So far we haven't see a lot of discussion/interest from the WG but your request is
>>>>>>>> perfectly fair.
>>>>>>> 
>>>>>>> Thank you - I aim to be fair.
>>>>>>> 
>>>>>>>> So far there are no details on the scenarios and testing environments that led to the issues that 
>>>>>>>> you reported, thus I would suggest you to first include them so that people interested could be able to reproduce
>>>>>>>> it. Once the drat is updated, we'll be happy to pool the WG.
>>>>>>>> 
>>>>>>>> Does that make sense ?
>>>>>>> 
>>>>>>> Not really. Let me explain my disagreement.
>>>>>>> 
>>>>>>> We tried RPL (and, I note, several different independent implementations of RPL) in a number of different scenarios and deployments, and observed the behaviors exhibited - noting that what we observed across the different implementations, scenarios and deployments was fairly universal.
>>>>>>> 
>>>>>>> We then went back to the specification, to understand these behaviors in detail, and understand their universality as independent from a specific scenario or deployment or implementation - but rather, as artifacts of the RPL protocol design.
>>>>>>> 
>>>>>>> We therefore believe that _any_ deployment, scenario or testing environment of RPL needs to pay attention to the issues presented, and find a way of addressing them. The way of addressing these issues in a given deployment or scenario would be appropriate for an "applicability statement" for that deployment or scenario.
>>>>>> 
>>>>>> JP> Thanks for the clarification; that being said, for the WG to make sure that nothing is "scenario" dependent and the outcome could indeed apply to all scenarios,
>>>>>> it might be worth being more explicit. For example, you pointed out to the MTU issue, to which I mentioned that 15.4g would bring a solution, so you may want to 
>>>>>> explain that you did not use 15.4g and there are a number of such examples ….
>>>>>> 
>>>>>>> 
>>>>>>> (For example, a deployment using only L2s which provides guaranteed bi-directional links  for L3 would address this by in the applicability statement stating "As all L2-links are guaranteed bi-directional, this addresses the issues raised in section 9 in draft-clausen-lln-rpl-experiences".)
>>>>>>> 
>>>>>>> Thus, we believe that it would actually be misleading (not to mention, unnecessarily verbose) to put the "details on the scenarios and testing environments" into this I-D.
>>>>>>> 
>>>>>>> Doing so would mislead the reader to believe that the issues presented only manifest themselves in those precise scenarios - which definitely isn't the case.
>>>>>> 
>>>>>> JP> see the previous comment and tell us what you think; we could provide other examples.
>>>>>> 
>>>>>> Note that we do not oppose to asking to the WG; we just request you first to add additional information to proceed forward.
>>>>>> 
>>>>>> thanks.
>>>>>> 
>>>>>> JP and Michael.
>>>>>> 
>>>>>> JP.
>>>>>> 
>>>>>>> 
>>>>>>> Best,
>>>>>>> 
>>>>>>> Thomas
>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> JP and Michael.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Best,
>>>>>>>>> 
>>>>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Roll mailing list
>>>>>> Roll@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll