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

[Thomas Heide Clausen <[e-mail]>]

Dear JP, Michael,

On May 16, 2012, at 17:48 , JP Vasseur wrote:

> Hi Thomas,
> 
> So … let me restate a few things:
> 
> 1) All implementations, reports about implementations and even more deployment reports are within the scope of our WG. To make it clear, we were not objecting to anything, just asking for more information about the ID before polling the WG, that's all.
> 

This I-D is, however, neither an implementation report nor a deployment report. It is a report on observations on that which has been published in the RPL RFC. These can be made even without an implementation.

We did conduct experiments, which lead us to observe phenomenons which we didn't expect. We then turned to the axioms (in this case, the RPL RFC) to explain those phenomenons - that explanation is this I-D.

(Or, do you believe that the anecdote about apple hitting Isaac Newton in the head is fundamental to understanding gravity?)

> 2) The point of the report is to give enough information for reproduce the results and prove or disprove . So this document requires more precision and a better description of which implementation were used, what tests have been run, … (as also pointed out by Cedric on the mailing list) => this seems what the WG is asking for.

No, that is precisely the point, it doesn't.

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.

> 2) We saw very little discussion on the mailing list before and after your presentation in Paris; it seems that we got emails from non authors also asking for more details before considering for WG adoption though …

My observation is, however, that as the details requested are immaterial to the observations in the I-D, there must be other reasons for which they are requested.....

> Again, the work is useful and we try to make it as useful as possible for the community.
> 

That is not what transpires from these emails.

Thomas

> Thanks again.
> 
> JP and Michael.
> 
> On May 16, 2012, at 3:56 PM, Thomas Heide Clausen wrote:
> 
>> Dear JP,
>> 
>> On May 16, 2012, at 15:54 , JP Vasseur wrote:
>> 
>>> Hi,
>>> 
>>> On May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote:
>>> 
>>>> 
>>>> On May 16, 2012, at 15:04 , JP Vasseur wrote:
>>>> 
>>>>> 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 
>>>> 
>>>> This particular issue is fairly well pointed out in section 6, which references RFC4919 (cf section 2 hereof) - the particular "small MTU" is not dependent on the specific 127 octets of a specific L2, but a set of observations that RPL - when faced with a small MTU - may often not be able to carry a complete control message in a single fragment. Section 6, 3rd paragraph is fairly explicit as to this.
>>>> 
>>>> More globally, the draft cites http://datatracker.ietf.org/wg/roll/charter/ - which (other than making specific reference to 802.15.4 (and not 15.4g) states that:
>>>> 
>>>> 	"In most cases, LLNs will be employed over link layers with 
>>>> 	 restricted frame-sizes, thus a routing protocol for LLNs should be
>>>> 	 specifically adapted for such link layers
>>>> 
>>>> We observe some limits on RPL within the framework that the ROLL charter has set forth.
>>>> 
>>>> I'm not sure I see what more can be done to address this point.
>>>> 
>>>>> and there are a number of such examples ….
>>>> 
>>>> 
>>>> Personally, I do not believe that there are, but  we (I think I can speak for all the authors here) would very much appreciate your being explicit on these examples - least it's hard to discuss them. 
>>> 
>>> Well put it differently, it would be beneficial to provide more details on your testing scenarios for the WG to make sure that nothing 
>>> is "scenario-dependent" and to make sure that the outcome could indeed apply to all scenarios, it might be worth being more explicit.
>>> 
>> 
>>> Could you do that before polling the WG ?
>>> 
>> 
>> Again, I think that reading the I-D, and the RPL RFC, should provide sufficient information where necessary. 
>> 
>> All of the issues we have brought forward can be understood by looking at the RPL RFC.
>> 
>> The "testing scenarios" simply pointed us to what we should look at in the RPL RFC
>> 
>> Best,
>> 
>> Thomas
>> 
>>> Thanks.
>>> 
>>> JP.
>>> 
>>>> 
>>>> Thomas
>>>> 
>>>>>> 
>>>>>> (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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>