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

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 11 May 2012 08:25:11 +0200

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?

Best,

Thomas, Ulrich, Yuichi, Jiazi and Axel

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 11 May 2012 14:58:37 -0500

Sorry I was not able to attend the IETF meeting. Were there
substantial comments for this document during the meeting? I looked at
the minutes and the discussion related to this draft seems rather
brief.

- om_p

On Fri, May 11, 2012 at 1:25 AM, Thomas Heide Clausen
<[email-masked]> wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Fri, 11 May 2012 21:10:39 -0700

> Thomas, Ulrich, Yuichi, Jiazi and Axel

As I alluded to in Paris, I don't really think this is currently a valid informational document; the document it *should* be is guidelines on how to implement RPL, not a description of a series of basic and naive mistakes. Unless we want a companion document, which for each of the issues raised says how to solve it.  We wouldn't write an RFC on someone's experience with congestion collapse after implementing a transport protocol without congestion control. Just my 2c.

Phil

---

From: Jiazi Yi <[email-masked]>
Date: Sat, 12 May 2012 13:26:51 +0200

Hi, 

As Thomas presented in Paris, this document is based on our experiences of RPL based on testbeds, simulations, etc. Of course, we are aware of the fact that we are far from smart, so we just followed the specification of RPL. I'm sorry for making those mistakes that are "basic and naive" for you, but we had tried our best. 

For the authors, we think this document is relatively complete on the aspect of "experience", rather than guidance -- of course, feedback and more experience are always welcome.  We would appreciate if there are smart ones who can make companion document educating us how to avoid those kind of "inexperienced" mistakes.

best

Jiazi Yi

http://www.jiaziyi.com
Hipercom@LIX, Ecole Polytechnique
Route de Saclay 91128 Palaiseau Cedex France

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 May 2012 09:18:08 +0200

Dear Thomas,

> 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. 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 ?

Thanks.

JP and Michael.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 14:08:43 +0200

Dear JP and Michael,

Thank you for your mail.

On May 16, 2012, at 09:18 , JP Vasseur wrote:

> 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 

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.

(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.

Best,

Thomas

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 May 2012 15:04:13 +0200

Dear Thomas,

> 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 iss…

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 ….

> 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.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 15:17:45 +0200

On May 16, 2012, at 15:04 , JP Vasseur wrote:

> 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. 

Thomas

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 16 May 2012 15:36:33 +0200

Hi dear JP,

> explain that you did not use 15.4g and there are a number of such examples ….

The document is based on the common scenarios of LLN, which means: constrained power, memory, energy, etc. 
In another words, it's "LLN-scenario" dependent. 

For example, regarding the MTU issue, it is said in the ROLL WG charter:

	- 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.

and in RFC 4919, the first characteristic of 6lowpan listed:

   1.   Small packet size.  Given that the maximum physical layer packet
        is 127 bytes, the resulting maximum frame size at the media
        access control layer is 102 octets.  Link-layer security imposes
        further overhead, which in the maximum case (21 octets of
        overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32
        and AES-CCM-64, respectively), leaves 81 octets for data
        packets.

More assumptions can be found in documents of 6lowpan and roll. Therefore, IMHO, it's safe to build the experience document based on those common assumptions. In contrast, it will be verbose to list all the possible special solutions/technologies. 

best 

YI Jiazi

http://www.jiaziyi.com

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 May 2012 15:54:42 +0200

Hi,

> 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 the…

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 ?

Thanks.

JP.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 15:56:58 +0200

Dear JP,

> 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

---

From: C Chauvenet <[email-masked]>
Date: Wed, 16 May 2012 14:13:56 +0000

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...
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 ?

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 ?
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.

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 ?
Identifying what is wrong in your implementation is a good first step, but the hardest part is to propose some corrections.

Best Regards,

Cédric Chauvenet.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 16 May 2012 09:53:57 -0500 (CDT)

I agree with Cedric. Issues that Cedric has raised are very basic and should have already been taken care of in the document. Seriously, do the authors think that this document would pass the muster for publication in any decent academic journal? Right now, the draft reads more like propaganda than information: written to bad mouth a protocol on the basis of biased/frivolous arguments. Why would the authors completely ignore P2P-RPL even though it resolves many issues they have pointed out. There are numerous similar sins of omission spread throughout the document. As a result, most conclusions the document reaches are open to doubt if not outright incorrect. Sure, RPL is not a perfect protocol - no protocol is. But this document is not an unbiased scientific analysis of the protocol. As Pascal said, this document could have served a valuable constructive purpose. But, perhaps this was not the intention of the authors. This document should be recognized for what it is: a political document written to further a particular destructive agenda.

Thanks
Mukul

----- Original Message -----
From: "C Chauvenet" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "roll WG" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Wednesday, May 16, 2012 9:13:56 AM
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Hi, 

Best Regards,

Cédric Chauvenet.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 17:08:10 +0200

Dear Cedric,

Thank you for your email. Comments below.

> 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). 

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.

> 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.

> 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....

> 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.

> 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. 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.

Thomas

> is a good first step, but the hardest part is to propose some corrections.
> Best Regards,
> 
> Cédric Chauvenet.
>

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 16 May 2012 11:40:24 -0400

> From: Thomas Heide Clausen <[email-masked]>
> Date: Wed, 16 May 2012 17:08:10 +0200
> 
> Again, the observations that we present in this I-D make
> exclusive reference to RPL, and not to a specific
> implementation or deployment.

While this is largely true, some of the observations are
based on experiments, and in those cases the details matter.
>From the draft:

   13.1.  Observations

   The varying link quality in real-world environments results in
   frequent changes of the best parent, which triggers a reset of the
   Trickle timer and thus the emission of DIOs.  Therefore Trickle does
   not converge as well for links that are fluctuating in quality as in
   theory.

A link is neither good nor bad but thinking makes it so.  What
sort of links were you using?  How did you measure link quality?
Different techniques have given very different results.

                                    -Richard Kelsey

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 May 2012 17:48:45 +0200

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.

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.

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 …

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

Thanks again.

JP and Michael.

---

From: C Chauvenet <[email-masked]>
Date: Wed, 16 May 2012 16:48:07 +0000

Thomas,
See inline,  

> 	(and, therefore, not "just" based on a single test). 

Does it means that your run multiple scenarios ? 
That would be great.

> 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 imma…

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 ....

> 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 b…

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.

> 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.

> 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 !
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".
> 

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.
So, because RPL is wide enough for multiple application, you have to take some time to tune it correctly, according to your application.
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.
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.
So my final position is that we disagree on the need of more details in your experiments.

Cédric.

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 16 May 2012 09:58:40 -0700

Mukul,

On Wed, May 16, 2012 at 7:53 AM, Mukul Goyal <[email-masked]> wrote:

> I agree with Cedric. Issues that Cedric has raised are very basic and
> should have already been taken care of in the document. Seriously, do the
> authors think that this document would pass the muster for publication in
> any decent academic journal?

I don't know since when that is any criteria for IETF work. Was it a
criteria for the standardization of RPL itself?

> Right now, the draft reads more like propaganda than information: written
> to bad mouth a protocol on the basis of biased/frivolous arguments.

I am sorry that you see the draft that way. We have tried to be as
objective as possible. Can you point out any concrete paragraph or section
that you see as "propaganda"? And honestly, I would have hoped that we can
have an objective, argumentative discussion on the mailing list, and not a
dismissal of our arguments without any constructive discussion.

> Why would the authors completely ignore P2P-RPL even though it resolves
> many issues they have pointed out.

1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is already
deployed.
2) There is no dependency from RPL to P2P-RPPL, i.e., it should work
stand-alone.
3) P2P-RPL is experimental, RPL is std. track.
4) I thought that ROLL is chartered to provide routing solutions for
extremely constrained devices (which was, I assume, one of the reasons to
not consider MANET work). One of our arguments in the draft is that RPL is
very complex (the specification alone plus necessary companion documents
has several hundred pages). Adding P2P-RPL as necessity to mitigate some of
the issues would increase the code size even more.

> There are numerous similar sins of omission spread throughout the
> document.

Where?

> As a result, most conclusions the document reaches are open to doubt if
> not outright incorrect.

Is that proof by authority or a real argument? Please be more constructive.

> Sure, RPL is not a perfect protocol - no protocol is. But this document is
> not an unbiased scientific analysis of the protocol.

How do you come to that conclusion? We provide concrete, objective
arguments. I do not see that in your email.

> As Pascal said, this document could have served a valuable constructive
> purpose. But, perhaps this was not the intention of the authors. This
> document should be recognized for what it is: a political document written
> to further a particular destructive agenda.
>

I really don't know what to say to that non-constructive argument.

Best regards
Ulrich

> 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...
> 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 ?
>
> 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.
>
> If not, does your draft mention the propositions that have been made to
> address the problems you point out in your draft ?
> Maybe you could add a "Resolution Proposal" section for each problem,
> gathering previous discussion and your own proposals ?
> Identifying what is wrong in your implementation is a good first step, but
> the hardest part is to propose some corrections.
>
> Best Regards,
>
> Cédric Chauvenet.
>
> >>> Thanks for your suggestion. So far we haven't see a lot of
> discussion/interest from the WG but your request is
> >>> perfectly fair.
> >>
> >>> you reported, thus I would suggest you to first include them so that
> people interested could be able to reproduce
> >> 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
> >> (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.
> >
> > 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,
> >>>>

---

From: Philip Levis <[email-masked]>
Date: Wed, 16 May 2012 10:02:56 -0700

> Could you do that before polling the WG ?

I think an example of what JP's talking about might be something such as the question I raised in Paris: what constitutes a "down link" in the testing? Thomas' response was "no ack after L2 retransmissions"; this is an assumption about behavior. How many retransmissions? What was the time spacing? It's not hard to configure 802.11, for example, such that L2 back off has only a tiny chance of successful delivery in the case of a hidden terminal. Most wireless protocol implementations today understand these issues and rely on much longer time frames to consider a link "down."

Phil

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 16 May 2012 10:09:17 -0700

JP,

On Wed, May 16, 2012 at 8:48 AM, JP Vasseur <[email-masked]> wrote:

> 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.
>

We did not intend that draft as "implementation" or "deployment report"
about one specific implementation. Many of the observations in the draft
are directly concluded from the RPL RFC, and not from an implementation. So
I second Thomas that providing more information about a single
implementation would not really help.

>
> 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.
>

Again, for a large part of the document, the observations are made from the
RPL spec. itself. Take for example the fragmentation issue; this would be
observed by any implementation, running on a constrained link layer, such
as in scope for ROLL.

>
> 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 …
>

Same argument as above. Our draft is not intended as implementation report
of a single implementation, but general observations of the RPL RFC. I
would hope that there is some discussion about the individual issues that
are described in the draft.

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

Thank you, JP, we appreciate that.

Best regards
Ulrich

> 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
> 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
> 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:
>
> 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.
>
> 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,
>
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 May 2012 19:05:20 +0200

indeed

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 19:11:28 +0200

Dear JP, Michael,

> 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 info…

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…

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…

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 19:37:30 +0200

Dear Cedric,

> Does it means that your run multiple scenarios ? 

As indicated elsewhere, yes. Although its details are immaterial to this discussion,

> 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 di…

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.

> 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.

> 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.

> 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.

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)

> 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.
> 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.

> 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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 19:52:01 +0200

Dear Mukul,

On May 16, 2012, at 16:53 , Mukul Goyal wrote:

> I agree with Cedric. Issues that Cedric has raised are very basic and should have already been taken care of in the document. Seriously, do the authors think that this document would pass the muster for publication in any decent academic journal?

I'm not sure that I follow this argument above. Was this a requirement for publication of the other ROLL documents?
Engineering != Research ?

> Right now, the draft reads more like propaganda than information: written to bad mouth a protocol on the basis of biased/frivolous arguments.

I am sorry, I take exception to those insinuations and accusations.

> Why would the authors completely ignore P2P-RPL even though it resolves many issues they have pointed out.

If RPL normatively required P2P-RPL, or if P2P-RPL was intended as "Obsoletes RPL", then this argument would have weight. As it is, IIRC, P2P-RPL is aiming for Experimental, and isn't an RFC?

> There are numerous similar sins of omission spread throughout the document. As a result, most conclusions the document reaches are open to doubt if not outright incorrect.

I am sorry, I also take exception to the above insult - dispensed without supporting evidence.

> Sure, RPL is not a perfect protocol - no protocol is. But this document is not an unbiased scientific analysis of the protocol.

I am sorry, I also take exception to the above insult - dispensed without supporting evidence.

> As Pascal said, this document could have served a valuable constructive purpose. But, perhaps this was not the intention of the authors.

I am sorry, I also take exception to the above insinuations and accusations. - dispensed without supporting evidence.

> This document should be recognized for what it is: a political document written to further a particular destructive agenda.

I am sorry, I also take exception to the above insult, insinuations and accusations. - dispensed without supporting evidence.

May I suggest that the discussion be brought up a notch, to address the technical issues raised in this I-D? 

Thomas
(who, fortunately, is equipped with a relatively thick skin)

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 16 May 2012 13:25:44 -0500 (CDT)

>>Seriously, do the authors think that this document would pass the muster for publication in any decent academic journal? 

>I don't know since when that is any criteria for IETF work. Was it a criteria for the standardization of RPL itself? 

RPL is a protocol specification whereas your document is an analysis of its performance. The performance analysis papers fall in academic domain and must follow a certain rigor and have a certain level of details when referring to experimental work. Your document fails to do so.

>I am sorry that you see the draft that way. We have tried to be as objective as possible. Can you point out any concrete paragraph or section that you see as "propaganda"? And honestly, I would have hoped that we can have an objective, argumentative discussion on the mailing list, and not a dismissal of our arguments without any constructive discussion. 

The problem is that the document is so biased that it is hard to see it any other way. A section-by-section review of the document coming in a couple of days. 

>1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is already deployed. 

So, you basically throw to dustbin 2+ years of hard work people have done on P2P-RPL? Even though it is designed to solve precisely the problems you highlight in your document? Same goes for the compression problem. The working group spent so much time deliberating on the problem and how best to solve it. But your document conveniently chose to ignore all that discussion. At the very least, your document could have been complete by listing all the issues people pointed out. 

>2) There is no dependency from RPL to P2P-RPPL, i.e., it should work stand-alone.

Then, no protocol should ever be extended. Each protocol must work well in all possible scenarios.
   
>3) P2P-RPL is experimental, RPL is std. track. 

So, P2P-RPL would never become standards track?

>4) I thought that ROLL is chartered to provide routing solutions for extremely constrained devices (which was, I assume, one of the reasons to not consider MANET work). One of our arguments in the draft is that RPL is very complex (the specification alone plus necessary companion documents has several hundred pages). Adding P2P-RPL as necessity to mitigate some of the issues would increase the code size even more. 

Two points:

1. A long RFC does not necessarily mean a complex protocol. Do you need to implement every thing in RPL RFC for a particular deployment? It would have been much more useful if your document had identified the minimal set of RPL features that MUST be present in each deployment.    

2. If you had added 34 pages of P2P-RPL to 157 pages of RPL RFC, it would not worsen the RPL's "complexity" too much. Would it? But then you would have much less to complain about RPL in your document.

>>There are numerous similar sins of omission spread throughout the document. 

>Where? 

Some additional sins I pointed out above. Please wait for my detailed review for a more complete list.

>>As a result, most conclusions the document reaches are open to doubt if not outright incorrect. 

>Is that proof by authority or a real argument? Please be more constructive. 

You reached the conclusions you reached based on incomplete arguments or by generalizing things that you saw in specific implementations/deployments. That is why these conclusions are doubtful.

>How do you come to that conclusion? We provide concrete, objective arguments. I do not see that in your email. 

Please see the previous comment.

>>As Pascal said, this document could have served a valuable constructive purpose. But, perhaps this was not the intention of the authors. This document should be recognized for what it is: a political document written to further a particular destructive agenda. 

>I really don't know what to say to that non-constructive argument. 

Rather than guiding a reader how to deploy RPL and avoid the potential pitfalls, your message is that RPL is so fundamentally flawed that it should be dumped altogether. This is any thing but constructive.

Thanks
Mukul

Thanks 
Mukul 

----- Original Message ----- 
From: "C Chauvenet" < [email-masked] > 
To: "JP Vasseur" < [email-masked] > 
Cc: "roll WG" < [email-masked] >, "Michael Richardson" < [email-masked] > 

Hi, 

Best Regards, 

Cédric Chauvenet.

---

From: Federico Consoli <[email-masked]>
Date: Wed, 16 May 2012 20:38:58 +0200

Il 16/05/2012 19.37, Thomas Heide Clausen ha scritto:
>>> On 16 May 2012, at 16:13, C Chauvenet<[email-masked]>  wrote:
>>>
>>>> Hi,
>>>>
Hi Thomas,

I have a question about this part, in particular Chapter 13 and its 
observation.

"The varying link quality in real-world environments results in frequent 
changes of the best parent, which triggers a reset of the Trickle timer 
and thus the emission of DIOs."

1) Why you reset trickle when you change preferred parent?

RFC 6550 Section 8.3  does not say that the change of the preferred 
parent MUST be considered inconsistencies with respect to the Trickle timer.

--

The scenario in the draft is: "69 RPL Routers (MSP430-based wireless 
sensor routers with IEEE 802.15.4, .. were positioned in a fixed grid 
topology."
I think you miss the distance between nodes. Without the distance I can 
not know the number of neighbors of each node, then the parameter K 
could also be "infinite" or else very binding.
However I think that conclusions like these (Section 13 - 13.1) depend 
on the type of scenario and it is very difficult to generalize.

Federico

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 16 May 2012 12:34:37 -0700

Mukul,

On Wed, May 16, 2012 at 11:25 AM, Mukul Goyal <[email-masked]> wrote:
> RPL is a protocol specification whereas your document is an analysis of its performance.

No, our draft is not a performance analysis, but outlines observations
of the RPL RFC.

> The performance analysis papers fall in academic domain

No. The IETF is about engineering, not academic research. Our draft
was submitted as Internet Draft to the IETF, and not as academic
publication.

> and must follow a certain rigor and have a certain level of details when referring to experimental work.

As Thomas noted, all the observations were directly based on the RPL
RFC; the experiments only triggered the deeper investigation of the
RPL RFC, and the observations described in our draft do not depend on
a specific implementation.

> Your document fails to do so.

This is an assertion, not a constructive argument.

> The problem is that the document is so biased that it is hard to see it any other way.

This is an assertion, not a constructive argument.

> A section-by-section review of the document coming in a couple of days.

Thank you, we appreciate that!

> So, you basically throw to dustbin 2+ years of hard work people have done on P2P-RPL?

That is not what I said.

> Even though it is designed to solve precisely the problems you highlight in your document?

Does that mean you agree that the problems mentioned in our draft are
accurate for RPL? In that case, I wonder why we need a companion
document to solve these problems in the first place, and why they have
not been solved in RPL. As written further down in this email, I would
like to point out again that P2P-RPL is Experimental, and therefore
"solving all the problems [we] highlight" in the Standards Tracks RPL
document is only possible to a very limited degree. The P2P-RPL also
does not officially "update" (in IETF terminology) RPL.

> Same goes for the compression problem. The working group spent so much time deliberating on the problem and how best to solve it.

I would very much like to discuss how to solve it. Our observations
are based on the RPL RFC (and other standards that are related); any
previous discussions on mailing lists only is irrelevant for these
observations. It would be very helpful if you pointed out concrete
suggestions to the appropriate sections in our draft.

> But your document conveniently chose to ignore all that discussion. At the very least, your document could have been complete by listing all the issues people pointed out.

Pointed out where? Our draft is based on the RPL standards, not
previous discussions on mailing lists.

> Then, no protocol should ever be extended. Each protocol must work well in all possible scenarios.

RPL is not "extended" by P2P-RPL. I don't see that the latter
officially updates or obsoletes the RFC. That would be impossible
anyway, since P2P-RPL is Experimental.

> So, P2P-RPL would never become standards track?

I understood that the current understanding of the ROLL WG is that
P2P-RPL is Experimental. It is, of course, possible to submit a new
draft in some years with intended Std. Track to update/obsolete the
Experimental version. But such a draft is not even planned, as far as
I know. Looking at other WGs, that process usually takes between 5-10
years, for gaining enough experience before publishing a new document
as std track.

> 1. A long RFC does not necessarily mean a complex protocol.

Well, not necessarily; but it may be an indication.

> Do you need to implement every thing in RPL RFC for a particular deployment? It would have been much more useful if your document had identified the minimal set of RPL features that MUST be present in each deployment.

I disagree. Such a recommendation should be made by the applicability
statements. Our draft does not give recommendations for implementers
in specific deployments, but describes general observations of RPL.

> 2. If you had added 34 pages of P2P-RPL to 157 pages of RPL RFC, it would not worsen the RPL's "complexity" too much. Would it? But then you would have much less to complain about RPL in your docum…

First, see my argument above (P2P-RPL does not "update" the RPL
specification, as Experimental draft).
Then, there is not just the RPL RFC, but also other required (read:
"normative") documents, which add to the already long RFC. I really
thought that we are talking about extremely constrained devices, but
it seems to me from your argument, that the devices are actually not
that constrained, so that it does not really matter much whether to
add another protocol.

> Some additional sins I pointed out above. Please wait for my detailed review for a more complete list.

Okay.

> You reached the conclusions you reached based on incomplete arguments or by generalizing things that you saw in specific implementations/deployments. That is why these conclusions are doubtful.

I disagree. These observations are based on the RPL RFC, and not on
specific implementations or deployments. We have delivered concrete
observations in the draft; just doubting them without counter-proof is
not constructive.

> Rather than guiding a reader how to deploy RPL and avoid the potential pitfalls, your message is that RPL is so fundamentally flawed that it should be dumped altogether. This is any thing but const…

I think we made it clear what our goals are (they are also described
in the draft).

Regards
Ulrich

---

From: Cedric-2 LAVENU <[email-masked]>
Date: Wed, 16 May 2012 21:43:11 +0200

Dear Mukul, all,

I think that the main goal of that doument is to raise issues that are 
inherent to the RPL RFC.
In my opinion, this I-D has been submitted to raise some concerns about 
the operation of RPL.
As it has been brought up several times, as any other protocol, the RPL 
specification will evolve in order to take into account observations 
listed over time.

As JP mentioned, it seems that constructive work is needed within ROLL to 
fix the identified gaps of the current spec. The response to that may be 
the addition of new mechanisms within future versions of the spec, or a 
clear statement about the limitations of the protocol.

From what has been previously said on the mailing list, I agree that time 
has to be invested to tune the protocol for each different application 
etc... but from what I understand, tuning an already existing set of 
parameters will not fill the technical gaps of a spec. As an end-user I'm 
even more concerned about that, since each vendor may have its own way to 
fill the gaps and to make the protocol work in a particular environment. 
However, interoperability is not guaranteed, which is a major concern for 
end-users targeting massive multi-vendor roll-outs.

I think it's in the scope of the working group to address each single 
concern identified in order to avoid these interop issues in the widest 
possible application area.

Best regards,
Cédric

[email-masked] a écrit sur 16/05/2012 20:25:44 :

> [email-masked] 
> Envoyé par : [email-masked]
> 
> 16/05/2012 20:25
> 
> A
> 
> [email-masked]
> 
> cc
> 
> [email-masked], [email-masked]
> 
> Objet
> 
> Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
> 
> >>Seriously, do the authors think that this document would pass the 
> muster for publication in any decent academic journal? 
> 
> >I don't know since when that is any criteria for IETF work. Was it 
> a criteria for the standardization of RPL itself? 
> 
> RPL is a protocol specification whereas your document is an analysis
> of its performance. The performance analysis papers fall in academic
> domain and must follow a certain rigor and have a certain level of 
> details when referring to experimental work. Your document fails to do 
so.
> 
>   
> >>Right now, the draft reads more like propaganda than information: 
> written to bad mouth a protocol on the basis of biased/frivolous 
arguments. 
> objective as possible. Can you point out any concrete paragraph or 
> section that you see as "propaganda"? And honestly, I would have 
> hoped that we can have an objective, argumentative discussion on the
> mailing list, and not a dismissal of our arguments without any 
> constructive discussion. 
> 
> The problem is that the document is so biased that it is hard to see
> it any other way. A section-by-section review of the document coming
> in a couple of days. 
> 
> >>Why would the authors completely ignore P2P-RPL even though it 
> resolves many issues they have pointed out. 
> 
> So, you basically throw to dustbin 2+ years of hard work people have
> done on P2P-RPL? Even though it is designed to solve precisely the 
> problems you highlight in your document? Same goes for the 
> compression problem. The working group spent so much time 
> deliberating on the problem and how best to solve it. But your 
> document conveniently chose to ignore all that discussion. At the 
> very least, your document could have been complete by listing all 
> the issues people pointed out. 
> 
> >4) I thought that ROLL is chartered to provide routing solutions 
> for extremely constrained devices (which was, I assume, one of the 
> reasons to not consider MANET work). One of our arguments in the 
> draft is that RPL is very complex (the specification alone plus 
> necessary companion documents has several hundred pages). Adding 
> P2P-RPL as necessity to mitigate some of the issues would increase 
> the code size even more. 
> 
> Two points:
> 
> 1. A long RFC does not necessarily mean a complex protocol. Do you 
> need to implement every thing in RPL RFC for a particular 
> deployment? It would have been much more useful if your document had
> identified the minimal set of RPL features that MUST be present in 
> each deployment.    
> 
> 2. If you had added 34 pages of P2P-RPL to 157 pages of RPL RFC, it 
> would not worsen the RPL's "complexity" too much. Would it? But then
> you would have much less to complain about RPL in your document.
> 
document. 
> 
> >Where? 
> 
> Some additional sins I pointed out above. Please wait for my 
> detailed review for a more complete list.
>   
> 
> You reached the conclusions you reached based on incomplete 
> arguments or by generalizing things that you saw in specific 
> implementations/deployments. That is why these conclusions are doubtful.
>   
> 
> >>Sure, RPL is not a perfect protocol - no protocol is. But this 
> document is not an unbiased scientific analysis of the protocol. 
> 
> >>As Pascal said, this document could have served a valuable 
> constructive purpose. But, perhaps this was not the intention of the
> authors. This document should be recognized for what it is: a 
> political document written to further a particular destructive agenda. 
> 
> 
> Rather than guiding a reader how to deploy RPL and avoid the 
> potential pitfalls, your message is that RPL is so fundamentally 
> flawed that it should be dumped altogether. This is any thing but 
> constructive.
> 
> Thanks
> Mukul
>   
> 
> 
> Thanks 
> Mukul 
> 
> 
> Cc: "roll WG" < [email-masked] >, "Michael Richardson" < [email-masked] 
> 
> 
> 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... 
> 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 ? 
> 
> discussions that occurred during the past year on various mailing 
> lists, and IETF meetings. 
> 
> If not, does your draft mention the propositions that have been made
> to address the problems you point out in your draft ? 
> Maybe you could add a "Resolution Proposal" section for each 
> problem, gathering previous discussion and your own proposals ? 
> Identifying what is wrong in your implementation is a good first 
> step, but the hardest part is to propose some corrections. 
> 
> Best Regards, 
> 
> Cédric Chauvenet. 
> 
> >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was 
> presented and discussed at the Paris meeting. 
> >>>> 
> >>> you reported, thus I would suggest you to first include them so 
> that people interested could be able to reproduce 
> 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. 
> >> 
> 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 
> >> (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. 
> > 
> > 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, 
> >>>> 

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

---

From: C Chauvenet <[email-masked]>
Date: Wed, 16 May 2012 22:28:42 +0000

Thomas, 

> 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 ?
If you think that you are not able to figure out yourself the problems you see in RPL, go buy some commercial solutions ;-)

> 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.

> 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.

---

From: Axel Colin de Verdiere <[email-masked]>
Date: Wed, 16 May 2012 16:44:39 -0700

Dear Cedric,

> 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

---

From: C Chauvenet <[email-masked]>
Date: Thu, 17 May 2012 00:11:34 +0000

Axel, 

> 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 o…

I guess you wanted to say "storing mode" in your last sentence.
Of course, they cannot disclose their results on the public place. If so, how could they justify the fee to enter the alliance ...
Same for their implementation parameters, Zigbee members are not working for the public community !
I wanted to let people know about other RPL implementations efforts, to help them to draw a global picture of how many people are using RPL.
But as you said, it is hard to know when data are not public.

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

Was just a humor tentative, and stating that RPL is already employed in commercial products and solutions.
In general, commercial products are stable.

Cédric.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 May 2012 02:31:19 +0200

On May 16, 2012, at 19:09, Ulrich Herberg wrote:

> Many of the observations in the draft are directly concluded from the RPL RFC

I'm a bit reluctant to pitch in here as I definitely don't want to take sides in what appears to be an argument (the sides of which I'm just starting to understand).

For me, the draft reads less as a list of observations, but as a list of hypotheses.
An extremely useful list, as I think most people commenting in this thread have agreed.

Where these hypotheses are generated by drawing conclusions from the specs, I think it is prudent to try to corroborate them based on actual experience.  Previously, people have concluded from the available physics that airplanes cannot fly.  Other people have proven them wrong.  I think there are a number of "heavier than air" arguments in the document, and there may be Bernoullis in this WG shaking their heads.  We need the scientific dispute to nail down these hypotheses.

Where these hypotheses are already corroborated by experiments, we need to know enough about these so it doesn't appear to be a "I tried to build an  airplane and it didn't fly" argument.  Some discussion of minimum standards for documentation could be found, say, in http://dx.doi.org/10.1145/1096166.1096174 -- I wouldn't want a WG document that also qualifies as one of "the incredibles".

The draft may lay the basis for/become an RFC 4815 style "here is some more information that allows you to do it right" document.  This may, in part, be an applicability statement, or it may contain additional specifications/constraints that are crucial to actually making things work and may later become part of a revised spec.

So what I'm saying here is that more work is needed on this document.  But I'm not saying the onus for this is *only* on its authors*):

If it becomes a custom that members of the WG say "smart people know how to make this work but we won't tell you how", this would demonstrate that RPL is a "trapdoor" spec -- it is useful only to those readers who already know how to interoperate, but it is not useful to create interoperability.  Of course, nobody is obliged to do the work to provide this kind of information, and it's certainly not our job to provide a basic engineering education.  But if too much of the information needed beyond that, is not becoming readily available, RPL is not a viable IETF standards-track specification and MUST be withdrawn.

Grüße, Carsten

*) (One of my pet peeves, after 30 years of standardization. Actually the point that is drawing me into this discussion against my better instinct.)

---

From: Omprakash Gnawali <[email-masked]>
Date: Wed, 16 May 2012 21:11:05 -0500

Here is a link to a constructive document on related topics we started
a while ago:

Recommendations for Efficient Implementation of RPL
http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03

(just wanted to refresh WG's memory)

As always, happy to edit the document with experiences from the trenches.

- om_p

---

From: Philip Levis <[email-masked]>
Date: Wed, 16 May 2012 22:02:32 -0700

Thomas,

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?

Phil

---

From: Martin Heusse <[email-masked]>
Date: Fri, 18 May 2012 22:46:54 +0200

Phil, 
what you are writing bellow may be true (although...) but it does not address comment 12, that we have no idea when DAOs should be sent and how DAOs should be handled (how long should the route be kept?). 

Along those lines, 2 comments:
1) I notice that draft-ietf-roll-applicability-ami, for instance, ignores DAOs except for specifying that DAOs SHOULD be sent -- so they might not be sent--, even though "Two-way communication is a requirement"(?). At the same time, this draft goes as far as suggesting what parameters to use for trickle (big deal) or for MaxRankIncrease (big deal: will things break if someone uses 512 instead of 1024?). 
(same comment applies to draft-gnawali-roll-rpl-recommendations-03.)
2) <sarcasm> What is the point of making DAOs compact in storing mode (learning the route recursively) while the packets that actually contain data have to carry the whole path anyway? </sarcasm> 

Best regards,
Martin

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 18 May 2012 18:37:35 -0500

Martin,

Is your concern that 6550 and
draft-gnawali-roll-rpl-recommendations-03 do not say the Trickle
interval should be a-b ms and hence it is easy to use a bad value and
bring the whole network down or make it run inefficiently?

- om_p

---

From: JP Vasseur <[email-masked]>
Date: Sat, 19 May 2012 21:39:52 +0200

Hi Martin,

co-chair hat off …

How often do you think that ISIS LSA should be refreshed ?
Or OSPF opaque LSA for TE extensions be flooded ?
Or BFD packets ? 
Or PCEP Keepalive when turned on ?

Very seriously … these questions apply to all protocols … and you cannot expect the specifications to give you
hard coded values (but default whenever possible); these are topology and application specific, don't you think ?

Thanks.

Cheers.

JP.

---

From: Martin Heusse <[email-masked]>
Date: Mon, 21 May 2012 12:18:34 +0200

Not at all.

I wrote that email firstly to react on Phil Levis' partial reaction. The subject was when to send and how to handle DAOs (comment 12 of draft-clausen). As far as I know, this is orthogonal to the trickle algorithm, isn't it? 

But then I wondered if maybe an applicability / recommendation draft would give more precise information on this topic (which could make sense, considering the fact that downward traffic is viewed as a requirement in the context of the applicability draft). It seems to me this is not the case, although I may have missed something. 

Best regards,
Martin

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 21 May 2012 10:45:49 -0500 (CDT)

Here is my review for first 9 sections of draft-clausen-lln-rpl-experiences-03. For later sections, I have nothing substaintial to add to what Philip has already said in the message below. 

One answer to many questions raised in draft-clausen is: use P2P-RPL. It is not the case that P2P-RPL must always be used simply because the problems it solves are not significant in all scenarios or application domains. But, where it makes sense, P2P-RPL can certainly be used. P2P-RPL is currently aiming for Experimental status. As more experience is gained with its operation, it will go for Standards Track status.

Thanks
Mukul

Section 4: Requirement Of DODAG Root
--------------------------------------

"RPL Routers provisioned with resources to act as DODAG Roots, and
   administratively configured to act as such, represent a single point
   of failure in the network.  As the memory requirements for the DODAG
   Root and for other RPL Routers are substantially different, unless
   all RPL Routers are provisioned with resources (memory, energy, ...)
   to act as DODAG Roots, effectively if the designated DODAG Root
   fails, the network fails and RPL is unable to operate.  Even if
   electing another RPL Router as temporary DODAG root (e.g., for
   forming a "Floating" DODAG) for providing internal connectivity
   between RPL Routers, this router may not have the necessary resources
   to satisfy this role as (temporary) DODAG Root.
"

If a deployment uses "RPL + P2P-RPL", the criticism listed above is not valid. There is no single point of failure. If the global DAG(s) cannot work because of the root's failure, the nodes can still discover routes to each other using P2P-RPL. Nodes do not need extra memory/CPU to run P2P-RPL.

"Another possible LLN scenario is that only internal point-to-point
   connectivity is sought, and no RPL Router has a more "central" role
   than any other - a self-organizing LLN.  Requiring special
   provisioning of a specific "super-node" as DODAG Root is both
   unnecessary and undesirable."

Such an LLN can just use P2P-RPL. No need for special provisioning for any node.  

Section 5:  RPL Data Traffic Flows
--------------------------------------

" RPL makes a-priori assumptions of data traffic types, and explicitly
   defines three such [I-D.ietf-roll-terminology] traffic types: sensor-
   to-root data traffic (multipoint-to-point) is predominant, root-to-
   sensor data traffic (point-to-multipoint) is rare and sensor-to-
   sensor (point-to-point) data traffic is extremely rare.  While not
   specifically called out thus in [RFC6550], the resulting protocol
   design, however, reflects these assumptions in that the mechanism
   constructing multipoint-to-point routes is efficient in terms of
   control traffic generated and state required, point-to-multipoint
   route construction much less so - and point-to-point routes subject
   to potentially significant route stretch (routes going through the
   DODAG Root in non-storing mode) and over-the-wire overhead from using
   source routing (from the DODAG Root to the destination) (see
   Section 7) - or, in case of storing mode, considerable memory
   requirements in all LLN routers inside the network (see Section 7).
"

P2P-RPL resolves any route stretch issues. Note that if the source and destination are far apart, the route stretch with core RPL is not much (i.e. the along-DAG routes wont be much worse than direct routes) although the constraint to traverse through the root may still cause congestion near the root. If source and destination are nearby, the route stretch with "along global DAG" route could be significant and that is where using P2P-RPL makes most sense.

Also, P2P-RPL supports discovery of both hop-by-hop routes and source routes. A source could choose which one to use for a particular destination. 

"The data traffic characteristics, assumed by RPL, do not represent a
   universal distribution of traffic types in LLNs:

   o  There are scenarios where sensor-to-sensor traffic is a more
      common occurrence, documented, e.g., in [RFC5867] ("Building
      Automation Routing Requirements in Low Power and Lossy Networks").

"

And in such cases, it makes sense to use P2P-RPL with or without core RPL.

"For the former, all sensor-to-sensor routes include the DODAG Root,
   possibly causing congestions on the communication medium near the
   DODAG Root, and draining energy from the intermediate RPL Routers on
   an unnecessarily long route.  If sensor-to-sensor traffic is common,
   RPL Routers near the DODAG Root will be particularly solicited as
   relays, especially in non-storing mode.
"

Use P2P-RPL.

Section 6:  Fragmentation Of RPL Control Messages And Data Packet
----------------------------------------------------------------
" While 79 octets
   may seem to be sufficient to carry RPL control messages, consider the
   following: RPL control messages are carried in ICMPv6, and the
   mandatory ICMPv6 header consumes 4 octets.  The DIO base another 24
   octets.  If link metrics are used, that consumes at least another 8
   octets - and this is using a hop count metric; other metrics may
   require more.  The DODAG Configuration Object consumes up to a
   further 16 octets, for a total of 52 octets.  Adding a Prefix
   Information Object for address configuration consumes another 32
   octets, for a total of 84 octets - thus exceeding the 79 octets
   available for L3 data payload and causing link-layer fragmentation of
   such a DIO. "

It is certainly possible for a DIO to exceed 79 bytes. But, it is not the case that a DIO would always fragment. DODAG Configuration Option is an "option" and so is the Prefix Information Option. Every DIO need not carry these options (or others defined in Section 6.7 of RPL RFC).

That being said, possible fragmentation of DIOs is a real issue. When designing a packet format, one always has to struggle to achieve a balance between the need to save space and the need to be modular - two conflicting goals. Pascal called the P2P Route Discovery Option (P2P-RDO, defined in P2P-RPL) a "garbage can option" because it includes all the information P2P-RPL route discovery needs (besides what is carried in the configuration option, the metric containers and the DIO base object). We designed P2P-RDO thinking that the need to save space is more critical. Various options defined in RPL RFC were designed giving more importance to the need for modularity. I dont think this is necessarily a bad thing as draft-clausen alleges. While many RPL deployments will use IEEE 802.15.4 as the link layer in near future, this may not always be the case. The correct solution to the problem of fragmentation in 802.15.4 LLNs is to devise a compression mechanism at 6lowpan level. Some thing similar to draft-bormann-6lowpan-ghc-04 or the RPL-specific compression scheme we proposed (draft-goyal-roll-rpl-compression but now working at 6lowpan layer).

"As a point of reference, the ContikiRPL [rpl-contiki]
   implementation includes both the DODAG Configuration option and the
   Prefix Information option in all DIO messages.  Any other options,
   e.g., Route Information options indicating prefixes reachable through
   the DODAG Root, increase the overhead and thus the probability of
   fragmentation.
"

OK, so a particular implementation always includes config and PI options in all DIOs. That sounds like a problem this particular implementation has created for itself.

"Given the minimal packet size of LLNs, the routing protocol must
   impose low (or no) overhead on data packets, hopefully independently
   of the number of hops [RFC4919].  However, source-routing not only
   causes increased overhead in the IP header, but also leads to a
   variable available payload for data (depending on how long the source
   route is)."

Again, this is not a simple one-sided issue. Yes, source routes eat precious bytes in the data packets. But, in many constrained environments (e.g. in some home automation deployments), only source routing is possible because devices are hard pressed for memory and cannot maintain any routing state.

"In point-to-point communication and when non-storing mode
   is used for downward traffic, the source of a data packet will be
   unaware of how many octets will be available for payload (without
   incurring L2.5 fragmentation) when the DODAG Root relays the data
   packet and add the source routing header.  Thus, the source may
   choose an inefficient size for the data payload: if the data payload
   is large, it may exceed the link-layer MTU at the DODAG Root after
   adding the source-routing header; on the other hand, if the data
   payload is low, the network resources are not used efficiently, which
   introduces more overhead and more frame transmissions.

"

This is a good point to make. Note that this problem is not present when the source (rather than the DAG root) itself includes the source route in the packet. So, this problem goes away when using P2P-RPL. 

Section 7: The DAO Mechanism: Downward and Point-to-Point Routes
---------------------------------------------------------------

"RPL specifies two distinct and incompatible "modes of operation" for
   downward traffic: storing mode, where each RPL Router is assumed to
   maintain routes to all destinations in its sub-DODAG, i.e., RPL
   Routers that are "deeper down" in the DODAG, and non-storing mode,
   where only the DODAG Root stores routes to destinations inside the
   LLN, and where the DODAG Root employs strict source routing in order
   to route data traffic to the destination RPL Router.
"

The above description of storing mode is incorrect. It is not the case that, in storing mode, each RPL Router maintains routes to all destinations in its sub-DODAG. The child decides which of its parents would receive a DAO. Further, for each advertized destination, the origin (of the advertisement) decides (via path control bits) how many separate routes could exist for this destination.

Section 7.1:

"In case a destination is
   unreachable, all the DODAG Root may do is require all destinations to
   re-issue their DAOs, by way of issuing a DIO with an increased DODAG
   version number, possibly provoking a broadcast-storm-like situation.
"

This problem is easily fixable by a simple DAO solicitation mechanism: root includes a solicitation in its DIO, routers in the DAG propagate the solicitation further in their DIOs and when the desired destination receives the solicitation, it sends the DAO to the root. Pascal has often talked about writing up this fix.

"A final point on the DAO mechanism: RPL supports point-to-point
   traffic only by way of relaying through the DODAG.  In networks where
   point-to-point traffic is no rare occurrence, this causes unduly long
   routes (with possibly increased energy consumption, increased
   probability of packet losses) as well as possibly congestion around
   the DODAG Root.
"

Use P2P-RPL in such scenarios.

Section 8: Address aggregation and summarization
------------------------------------------------------
I dont agree with the assertion that address aggregation will break down completely if a node's DAO parent is not same as the one whose advertized prefix was used by the node to configure its address. I think DAO parent selection at lower levels wont have too much impact on address aggregation at nodes at upper level. Sure address aggregation may not be possible at the node's parent or grandparent. But, nodes still higher up will be less and less affected.

Also, there might be factual inaccuracy in the text below.

" Any aggregated routes require the use of a prefix shorter than /64,
   and subsequent hierarchical assignment of prefixes down to a /64 (as
   any RPL Router itself provides a /64 subnet to any hosts connected to
   the router).

   Moreover, if the 6lowpan adaption layer [RFC4944] is used in the LLN,
   route aggregation is not possible since the same /64 is applied
   across the entire network."

I dont think an RPL router has to always advertize a 64 bit prefix to its hosts. Further, with RFC 6282, I am not sure if only /64 prefix could be used for autoconfiguration of 802.15.4 interfaces. So, the assertion "Any aggregated routes require the use of a prefix shorter than /64" may not be true.

Section 9: Link assumed bidirectional
-------------------------------------------------

"Unidirectional links are no rare occurrence, such as is known from
   wireless multi-hop networks.  Preliminary results from a test-bed of
   AMI (Automated Metering Infrastructure) devices using 950MHz radio
   interfaces, and with a total of 22 links, show that 36% of these
   links are unidirectional."
 
Could the authors provide reference to published literature showing that a significant fraction of links are unidirectional? The reference to an unpublished/unavailable study is not OK. Also, it seems that "950MHz" is a typo.

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "Thomas Heide Clausen" <[email-masked]>
Cc: "roll WG" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Thursday, May 17, 2012 12:02:32 AM
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Thomas,

Phil

---

From: Martin Heusse <[email-masked]>
Date: Tue, 22 May 2012 16:40:43 +0200

Jean-Philippe,

> Or OSPF opaque LSA for TE extensions be flooded ?
--> "It depends"?
I am not saying that we would need to mention in the (general) RFC when, or at which rate,
- global repairs should take place or;
- DAO should be sent out on a regular basis…
(Although this could perfectly appear in applicability, isn't it?)

My point was that the DAO mechanisms are not so clearly defined... Which may be fine: then Mukul is right and if you really need to reach everyone, then P2P RPL is there...
Right now, there can be a problem with DAOs
- if they are lost along the way (not unlikely if not using DAO-ACKs **even with L2 ACKs**, still possible otherwise) 
- if a sub-dodag moves... all routes are broken, and we don't really know how to re-establish them (although DTSN could help here, although it's a little vague)
- if an inconsistency is detected on a downward route, you'd have to ask everyone to re-send DAOs (Pascal's DAO requests would have helped of course -- this shows up on the list every now and then).

--> for opaque LSA, the information in the packet does not matter, but the flooding mechanism is robust and well defined. For DAOs, we know how the packet must look like...

> hard coded values (but default whenever possible); these are topology and application specific, don't you think ?
Yes, I agree! 

Martin