Subject: Re: [Roll] [roll] #29: DIS packet format

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Apr 2010 11:29:36 +0200

Hi:

From theads and discussions, I'd think that the conclusion could be to make sure we do not disallow options in the future, but for the short term to only specify what we really need.
What we really need to probably the DODAG ID (UNSPECIFIED if none) and the instance ID (0 by default). I think those 2 should be in the common header and not in an option.

Advice?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of roll
> issue tracker
> Sent: Monday, March 29, 2010 5:47 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Roll] [roll] #29: DIS packet format
> 
> #29: DIS packet format
> --------------------------------+---------------------------------------
> --------------------------------+----
>  Reporter:  jpv@…               |       Owner:  wintert@…
>      Type:  task                |      Status:  new
>  Priority:  major               |   Milestone:
> Component:  rpl                 |     Version:
>  Severity:  Active WG Document  |    Keywords:
> --------------------------------+---------------------------------------
> --------------------------------+----
>  Consensus on the ROLL ML to change the DIS packet format and make the
> body  capable of carrying TLVs, with no TLV defined in the core specification.
> 
> --
> Ticket URL: <https://trac.tools.ietf.org/wg/roll/trac/ticket/29>
> roll <http://tools.ietf.org/wg/roll/>
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Fri, 2 Apr 2010 16:39:03 +0200

I think that the consensus was also to slightly change the DIS packet  
format to allow for future options to be carried in the form of TLV  
(as we do in many other protocols) , which is not possible with the  
current packet format.

WG ?

JP.

On Apr 2, 2010, at 11:29 AM, Pascal Thubert (pthubert) wrote:

> Hi:
>
> From theads and discussions, I'd think that the conclusion could be  
> to make sure we do not disallow options in the future, but for the  
> short term to only specify what we really need.
> What we really need to probably the DODAG ID (UNSPECIFIED if none)  
> and the instance ID (0 by default). I think those 2 should be in the  
> common header and not in an option.
>
> Advice?
>
> Pascal
>
>

---

From: Phoebus Chen <[email-masked]>
Date: Sun, 04 Apr 2010 23:52:35 +0200

JP and WG,

Maybe this should be a standard option instead of a TLV, but as I 
mentioned in an earlier email, I think it's clearer to use flags or 
options in the DIS to specify that a node is
a) requesting a DODAG Configuration Object (or some other suboptions in 
the DIO), and
b) not wanting to reset the Trickle timer,
rather than define that as the functionality of a unicast DIS message 
(as opposed to a multicast DIS message, RPLv7, Sec. 5.3.5., pg. 36).

Just putting this back on the table with the other DIS suboptions being 
discussed, to help with the decision of a packet format.

--
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus

On 4/2/10 4:39 PM, JP Vasseur wrote:
>>> Ticket URL:<https://trac.tools.ietf.org/wg/roll/trac/ticket/29>
>>> roll<http://tools.ietf.org/wg/roll/>
>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Apr 2010 10:41:54 +0200

All/

I agree with the RPL standard options, which by the way are TLVs of
sort.
Does not mean that we have to define a single option so far, but maybe
allow for padding.
Still, Phil's point stands. There are things that are needed most time
and even options is overkill.
In particular the instance ID, and probably a few flags like Phoebus
points out.
What about:

" XXX DODAG Information Solicitation (DIS)  

  The DODAG Information Solicitation (DIS) message may be used to
   solicit a DODAG Information Object from a RPL node.  Its use is
   analogous to that of a Router Solicitation; a node may use DIS to
   probe its neighborhood for nearby DODAGs.  Section 6.2.4 describes
   how nodes respond to a DIS.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |D|O|C|reserved |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       +                                                               +
       |            DODAGID (If D flag set)                           |
       +                                                               +
       |                                                               |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |   Option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 5: DIS Base

   RPLInstanceID:  8-bit field set by the DODAG root that indicates
         which RPL Instance the DODAG is part of.

   D flag:  Set if the DODAGID is present.

   O flag:  Set to request a DODAG Configuration Object

   C flag:  Set if the requester expects no inconsistency, just
         revalidation.

   DODAGID:  128-bit unsigned integer set by a DODAG root which uniquely
         identifies a DODAG.  Possibly derived from the IPv6 address of
         the DODAG root.  The field can be omitted when the node does
         not look for a DODAG root in particular.  

   The DODAG Information Solicitation MAY carry options.  With this
   specification only the padding (Pad1 and PadN) option MAY be used in
   a DIS messsage. < TBD, list of OFs? >

"
Pascal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Phoebus Chen
> Sent: Sunday, April 04, 2010 11:53 PM
> To: [email-masked]
> Subject: Re: [Roll] [roll] #29: DIS packet format
> 
> JP and WG,
> 
mentioned
> in an earlier email, I think it's clearer to use flags or options in
the DIS to
> specify that a node is
> b) not wanting to reset the Trickle timer, rather than define that as
the
> functionality of a unicast DIS message (as opposed to a multicast DIS
> message, RPLv7, Sec. 5.3.5., pg. 36).
> 
> >>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> >>> Of roll issue tracker
> >>> Reporter:  jpv@...               |       Owner:  wintert@...
> >>>      Type:  task                |      Status:  new
> >>> Consensus on the ROLL ML to change the DIS packet format and make
> >>> the body  capable of carrying TLVs, with no TLV defined in the
core
> >>> specification.

---

From: Philip Levis <[email-masked]>
Date: Mon, 5 Apr 2010 10:13:53 -0700

> In particular the instance ID, and probably a few flags like Phoebus

Pascal,

Can you outline what you see as the benefits/drawbacks/tradeoffs in comparison to my proposal?

My two cents: 

1) The C flag seems strange -- what does it mean? When would a DIS indicate an inconsistency? 

2) The approach requires *all* DIS messages to contain this information, which seems wasteful. My intuition is that support for DIS information filters ought to be a MAY, as it's an optimization that might be very useful or might be irrelevant. If the former, implementations will include it and later down the line it can become a SHOULD or MUST. If the latter, no-one will use it and it can die out.

3) Why the O-flag? This is what unicast DIS messages are for.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Apr 2010 20:06:38 +0200

Hi Phil:

Both flags comes from Phoebus' mail. And I tend to agree with him in
both cases.

With the current draft, a DIS from a node forces the router that
receives it to reset its trickle timer. Yet it makes sense for a node to
poll its router to make sure it is lively, and that does not mean
inconsistency. Thus the C flag to indicate that it's just a check, no
worries.

About the O flag, it seems that today we confuse the method (mcast vs.
unicast) with the goal (get parameters or not). I do not think that such
a semantical stretch will serve us in the long term. Better call a cat a
cat, wouldn't you think?

Let's see what others think about what should be in the base DIS and
what should be in a new option.

Pascal

> From: Philip Levis [mailto:[email-masked]]
> Sent: Monday, April 05, 2010 7:14 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> 1) The C flag seems strange -- what does it mean? When would a DIS
indicate
> an inconsistency?
> 
> 2) The approach requires *all* DIS messages to contain this
information,
> which seems wasteful. My intuition is that support for DIS information
filters
> ought to be a MAY, as it's an optimization that might be very useful
or might
> be irrelevant. If the former, implementations will include it and
later down
> the line it can become a SHOULD or MUST. If the latter, no-one will
use it and
> it can die out.

---

From: Philip Levis <[email-masked]>
Date: Mon, 5 Apr 2010 20:24:10 -0700

> inconsistency. Thus the C flag to indicate that it's just a check, no

Check of what? Is the intention that this is an alternative to ping? A DIS does not indicate an inconsistency: a DIS indicates that a node desires destination information from its neighbors. It can do so for all kinds of reasons. Not resetting a trickle timer is dangerous, due to trickle suppression. An immediate response will suppress other trickle messages. What happens if the C flag is set but the message is multicast? 

> a semantical stretch will serve us in the long term. Better call a cat a

Except that unicast vs. multicast relate to whether suppression is used. This then ties into the use of Trickle timers. Fundamentally, a node needs to respond differently to multicast and unicast.

That being said, an O flag does seem useful. Otherwise a node must first issue a multicast DIS and then a unicast DIS. But it would seem like this is a better design tradeoff to consider, rather than simply introducing a redundant mechanism. If DIS messages include the O flag, should we then remove the MUST from unicast DIS processing? 

If a node hears a DIS with the O flag set, does the presence or absence of a configuration suboption affect suppression?

Phil

---

From: Phoebus Chen <[email-masked]>
Date: Tue, 06 Apr 2010 15:32:57 +0200

On 4/6/10 5:24 AM, Philip Levis wrote:
>> Both flags comes from Phoebus' mail. And I tend to agree with him
>> in both cases.
>>
>> receives it to reset its trickle timer. Yet it makes sense for a
>> node to poll its router to make sure it is lively, and that does
>> not mean inconsistency. Thus the C flag to indicate that it's just
>> a check, no worries.
>
> Check of what? Is the intention that this is an alternative to ping?
> A DIS does not indicate an inconsistency: a DIS indicates that a node
> desires destination information from its neighbors. It can do so for
> all kinds of reasons. Not resetting a trickle timer is dangerous, due
> to trickle suppression. An immediate response will suppress other
> trickle messages. What happens if the C flag is set but the message
> is multicast?
>

I think that part of the confusion is that most of the dialog
surrounding resetting the Trickle timer assumes that we only reset the
Trickle timer upon detecting an inconsistency. My understanding of how
the Trickle timer is being used in this situation is
that we are resetting the Trickle timer after hearing a multicast DIS
to get more reliability of DIO message delivery, sort of as a
replacement for an acknowledgment by having more frequent
retransmissions for a short while.  Which is really stretching the
Trickle timer to do more than what it was originally designed to do
(detect and resolve inconsistency), but I digress.

We can rename the C flag to an R flag, for "reset Trickle timer", if
that clears up the confusion.  But in any case, I think that resetting
the Trickle timer should not be tied to unicast or multicast.  I see no
reason to restrict all multicast DIS messages to always reset the
Trickle timer, if you want to keep the mechanisms flexible.  It's not
entirely clear to me that forcing a Trickle timer reset is always
cheaper, in terms of routing control message overhead, than having a
node multicast a DIS again (no Trickle timer reset) if it does not feel
it has heard enough responses.  Remember, some deployments may choose to
turn off the suppression mechanism in Trickle (we have the ability to
set DIORedundancyConstant = 0xFF) so that it can hear all DIO
advertisements.

Another way to look at it is: Does RPL "break" if we allow unicast DIS 
messages to reset the Trickle timer, or multicast DIS messages to not 
reset the Trickle timer?  Are we ready to make such a decision, now, 
that those two cases are always bad?

BTW, I generally do want to rein in the ambiguity of how RPL behaves. 
If it turns out that there are very few situations where we would want 
to reset the Trickle timer after receiving a unicast DIS (or not reset 
the Trickle timer after receiving a multicast DIS) the specification can 
make recommendations on how to set the flags for those DIS messages.

>>
>> About the O flag, it seems that today we confuse the method (mcast
>> vs. unicast) with the goal (get parameters or not). I do not think
>> that such a semantical stretch will serve us in the long term.
>> Better call a cat a cat, wouldn't you think?
>
> Except that unicast vs. multicast relate to whether suppression is
> used. This then ties into the use of Trickle timers. Fundamentally, a
> node needs to respond differently to multicast and unicast.
>
> That being said, an O flag does seem useful. Otherwise a node must
> first issue a multicast DIS and then a unicast DIS. But it would seem
> like this is a better design tradeoff to consider, rather than simply
> introducing a redundant mechanism. If DIS messages include the O
> flag, should we then remove the MUST from unicast DIS processing?
>

Hmm, I'm not sure that I agree that issuing a multicast DIS and then a 
unicast DIS is a better design tradeoff than adding a 1-bit flag to the 
DIS message.

I think the idea here is to replace the text in Section 5.3.5 on how to 
handle unicast and multicast messages.  Instead, that should be under a 
description of how to respond to a DIS message depending on what flags 
are set.

> If a node hears a DIS with the O flag set, does the presence or
> absence of a configuration suboption affect suppression?
>
> Phil

---

From: Philip Levis <[email-masked]>
Date: Tue, 6 Apr 2010 10:11:39 -0700

> (detect and resolve inconsistency), but I digress.

If you do not reset the Trickle timer, what do you do? You can't immediately respond: that's a broadcast storm. Take a look at the results in the Trickle paper: one of the key properties of the exponential timer is that it scales to high variations in density. 

> the Trickle timer should not be tied to unicast or multicast.  

It is absolutely critical that it be tied to it: unicast packets do not cause a broadcast storm. If this means that the draft says that multicast packets MUST have the flag set, that would be fine.

> I see no
> it has heard enough responses.

The problem is too many responses. 

>  Remember, some deployments may choose to

Sure -- but the exponential timer will cause nodes to eventually reach a communication rate that the link layer can support.

> 
> Another way to look at it is: Does RPL "break" if we allow unicast DIS messages to reset the Trickle timer, or multicast DIS messages to not reset the Trickle timer?  Are we ready to make such a decision, now, that those two cases are always bad?

If a multicast message does not reset the trickle timer, but instead elicits an immediate response, that will break RPL.

It is OK for a unicast message to reset the Trickle timer.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 6 Apr 2010 23:05:12 +0300

Question:

I understand that responding immediately causes broadcast storms. But our
initial concern was that resetting the trickle timer by all devices
hearing a multicast DIS in a dense network, may also cause congestion by
DIO responses (assuming no suppression is used).

I was wondering whether a quick exponentially decaying reduction or
reduction with probability of the timer do instead of a full timer reset
(maybe multiplication or probability factors can be set on the DIS
message)? For unicast DIS, the factors can indicate 100% timer reset.

This can allow the DIS transmitter to make a flexible protocol that allows
for multiple "waves" of DIS messages to be sent by the same node, where
the probability or the reduction factor starts off small, and is increased
gradually if the DIS transmitter requires more DIO responses. This
protocol would also converge much faster if we can come up with a way of
not sending DIOs that were already sent in previous "waves" (but let's
focus on one problem solving at a time :) )

Thanks,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Tuesday, April 06, 2010 8:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] [roll] #29: DIS packet format

> (detect and resolve inconsistency), but I digress.

If you do not reset the Trickle timer, what do you do? You can't
immediately respond: that's a broadcast storm. Take a look at the results
in the Trickle paper: one of the key properties of the exponential timer
is that it scales to high variations in density.

> the Trickle timer should not be tied to unicast or multicast.

It is absolutely critical that it be tied to it: unicast packets do not
cause a broadcast storm. If this means that the draft says that multicast
packets MUST have the flag set, that would be fine.

> set DIORedundancyConstant = 0xFF) so that it can hear all DIO

Sure -- but the exponential timer will cause nodes to eventually reach a
communication rate that the link layer can support.

messages to reset the Trickle timer, or multicast DIS messages to not
reset the Trickle timer?  Are we ready to make such a decision, now, that
those two cases are always bad?

If a multicast message does not reset the trickle timer, but instead
elicits an immediate response, that will break RPL.

Phil

---

From: Phoebus Chen <[email-masked]>
Date: Tue, 06 Apr 2010 22:53:14 +0200

On 4/6/10 7:11 PM, Philip Levis wrote:
>>>> Both flags comes from Phoebus' mail. And I tend to agree with
>>>> him in both cases.
>>>>
>>>> With the current draft, a DIS from a node forces the router
>>>> that receives it to reset its trickle timer. Yet it makes sense
>>>> for a node to poll its router to make sure it is lively, and
>>>> that does not mean inconsistency. Thus the C flag to indicate
>>>> that it's just a check, no worries.
>>>
>>> Check of what? Is the intention that this is an alternative to
>>> ping? A DIS does not indicate an inconsistency: a DIS indicates
>>> that a node desires destination information from its neighbors.
>>> It can do so for all kinds of reasons. Not resetting a trickle
>>> timer is dangerous, due to trickle suppression. An immediate
>>> response will suppress other trickle messages. What happens if
>>> the C flag is set but the message is multicast?
>>>
>>
>> surrounding resetting the Trickle timer assumes that we only reset
>> the Trickle timer upon detecting an inconsistency. My understanding
>> of how the Trickle timer is being used in this situation is that we
>> are resetting the Trickle timer after hearing a multicast DIS to
>> get more reliability of DIO message delivery, sort of as a
>> Trickle timer to do more than what it was originally designed to
>> do (detect and resolve inconsistency), but I digress.
>
> immediately respond: that's a broadcast storm. Take a look at the
> results in the Trickle paper: one of the key properties of the
> exponential timer is that it scales to high variations in density.
>

Yes, you will get a 1-hop broadcast storm.  Which could be bad if the 
network were really dense.

>
>> We can rename the C flag to an R flag, for "reset Trickle timer",
>> if that clears up the confusion.  But in any case, I think that
>> resetting the Trickle timer should not be tied to unicast or
>> multicast.
>
> It is absolutely critical that it be tied to it: unicast packets do
> not cause a broadcast storm. If this means that the draft says that
> multicast packets MUST have the flag set, that would be fine.
>
>
>> I see no reason to restrict all multicast DIS messages to always
>> reset the Trickle timer, if you want to keep the mechanisms
>> flexible.  It's not entirely clear to me that forcing a Trickle
>> timer reset is always cheaper, in terms of routing control message
>> overhead, than having a node multicast a DIS again (no Trickle
>> timer reset) if it does not feel it has heard enough responses.
>
>> Remember, some deployments may choose to turn off the suppression
>> mechanism in Trickle (we have the ability to set
>> DIORedundancyConstant = 0xFF) so that it can hear all DIO
>> advertisements.
>
> Sure -- but the exponential timer will cause nodes to eventually
> reach a communication rate that the link layer can support.
>

Without suppression, you would have as much of a broadcast storm as a 
one time immediate response.  Minus the effects of the T/2 randomization 
for the sending times in Trickle.  If you're concerned about congestion 
from sending at the same time (as opposed to concern about the number of 
messages), remember that the MAC layer should probably be handling this: 
for example, that's what CSMA with exponential backoff is suppose to handle.

>>
>> Another way to look at it is: Does RPL "break" if we allow unicast
>> DIS messages to reset the Trickle timer, or multicast DIS messages
>> to not reset the Trickle timer?  Are we ready to make such a
>> decision, now, that those two cases are always bad?
>

I wouldn't say that RPL "breaks" if we elicit an immediate response. 
It's just highly inefficient in very dense networks.  There might be 
networks which are not dense too.  Using Trickle seems to bring it's own 
set of questions of how to do suppression properly - I currently don't 
have a clear grasp of all of Trickle's implications on how RPL behaves 
(and I have looked at the Trickle paper, but it's for a different 
scenario than RPL).  Allowing a multicast message to elicit an immediate 
response would leave another option for sparse networks, if strange 
behavior arises from using Trickle.

But in any case, maybe this discussion is straying off the main point... 
using flags in the DIS message to signal a trickle timer reset does not 
limit us from saying "multicast packets MUST have the flag set" later 
on, if further discussion and studies really point us in that direction 
as you say it should.

---

From: Phoebus Chen <[email-masked]>
Date: Tue, 06 Apr 2010 22:59:13 +0200

> focus on one problem solving at a time :) )

That's an interesting proposal.  Could be an interesting research 
problem.  But I'm quite nervous about introducing a really new mechanism 
into the standard here... I have trouble understanding the implications 
of using Trickle in RPL.  I think I'll have even more trouble 
understanding the implications of this in RPL ;).

---

From: Philip Levis <[email-masked]>
Date: Tue, 6 Apr 2010 14:17:56 -0700

> DIO responses (assuming no suppression is used).

This seems like a big assumption.

> message)? For unicast DIS, the factors can indicate 100% timer reset.

That's an interesting question: seems like the exact kind of thing that simulations, validated by experiments on real networks, can evaluate.

> focus on one problem solving at a time :) )
 
This sounds like a very interesting idea. But does it matter?

My concern is that Trickle has been demonstrated to work well in multiple protocol implementations with years of experience behind them. This doesn't mean that Trickle is perfect: Joakim has pointed out how there can be some unbalanced edge cases. But the goal here (RPL WG) isn't to come up with new, interesting ideas, but rather to standardize current, well-established practice.

With my academic hat on, I think think this is a fascinating direction for investigation and research. With my engineering hat on, I am very skeptical.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Wed, 7 Apr 2010 01:21:05 +0300

Thanks for the response.
See my comments in body of text.

-----Original Message-----
From: Philip Levis [mailto:[email-masked]]
Sent: Wednesday, April 07, 2010 12:18 AM
To: Yoav Ben-Yehezkel
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] [roll] #29: DIS packet format

<<yoav>> Maybe - but the question is whether RPL has to work under this
worst case assumption? I don't know the answer. Was hoping to get the
input from the WG. <</yoav>>

> message)? For unicast DIS, the factors can indicate 100% timer reset.

That's an interesting question: seems like the exact kind of thing that
simulations, validated by experiments on real networks, can evaluate.
<<yoav>> I agree. Are there WG members with a ready simulation that can
quickly check this? <</yoav>>

My concern is that Trickle has been demonstrated to work well in multiple
protocol implementations with years of experience behind them. This
doesn't mean that Trickle is perfect: Joakim has pointed out how there can
be some unbalanced edge cases. But the goal here (RPL WG) isn't to come up
with new, interesting ideas, but rather to standardize current,
well-established practice.

<<yoav>> I agree and I wasn't insinuating that this will be part of RPL
specification, I was just pointing out that this field of multiplication
or probability factor could leave lots of flexibility and enhancements
should someone try this direction for future research or even proprietary
use.

I really see one proprietary place where it matters from our experience in
low speed PLC networks.

We see asymmetry of more than 20db difference on opposite links caused by
Receiver noises and Transmitter loads, so unlike the wireless media - for
us the assumption that a opposite link exists when receiving a DIO cannot
be implicit in many cases. Loosing the link with a parent from the parent
set without the parent loosing the link with the child is common and doing
lots of pings is a waste. So having a DIS/DIO session occasionally would
really help to quickly find alternate parents+update rank, and filtering
DIO responses would also help in these cases.
Does use of this kind of algorithm can remain proprietary as long as the
behavior of the transmitter transmitting the DIS and receiver once
receiving the DIS packet follows the critical MUST path of RPL? <</yoav>>

With my academic hat on, I think think this is a fascinating direction for
investigation and research. With my engineering hat on, I am very
skeptical.

<<yoav>> :) With my academic hat on & :( with my engineering hat on.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Apr 2010 11:50:26 +0200

Hi Phil and Yoav:

Do you think we can conclude on this? At the moment I do not know what
to do for 08.

- about placing the instance and the DODAGID in the base DIS (similar to
other messages) or invent an option for that
- about Phoebus' flags.

For the O-flag:

The flag makes explicit the request for an option, arguing that the
presence of that option should not be inferred from the fact that a
packet is unicast or mcast. Is there an objection to this flag?

For the C-flag:

It is Fair & Square to me that the DIO is fired after a random timer to
eliminate hidden terminal, avoid sync effect, etc... And that excess of
DIO response must be trickled out. And it is also very probable that the
source of the DIS will see more DIOs than any of the routers playing
trickle so it should get more than enough DIOs if trickle really filters
some out. And if that's not enough, then the node can reissue a DIS, and
the randomness in trickle will make it so that other routers reply. So I
agree that this aspect of trickle plays there perfectly.  

What troubles me is that past the wave of answers to the DIS, the
routers will have to redo the exponential backoff game of multiplying by
2 till the max is reached. If there's no inconsistency to fix in the
first place, then the routers should right away restore the previous
value of their trickle timer, wouldn't you think?

If so, then please go ahead and propose text for those flags that's
clearer than the original proposal.

Cheers,

Pascal

Of
> Yoav Ben-Yehezkel
> Sent: Wednesday, April 07, 2010 12:21 AM
> To: Philip Levis
> Cc: [email-masked]; [email-masked]
> > I understand that responding immediately causes broadcast storms.
But
> our
> > hearing a multicast DIS in a dense network, may also cause
congestion
> > by DIO responses (assuming no suppression is used).
> 
> > reduction with probability of the timer do instead of a full timer
> > reset (maybe multiplication or probability factors can be set on the
> > DIS message)? For unicast DIS, the factors can indicate 100% timer
reset.
> > for multiple "waves" of DIS messages to be sent by the same node,
> > where the probability or the reduction factor starts off small, and
is
> increased
> > protocol would also converge much faster if we can come up with a
way
> > of not sending DIOs that were already sent in previous "waves" (but
> > let's focus on one problem solving at a time :) )
> >
> 
> with new, interesting ideas, but rather to standardize current, well-
> established practice.
> 
> specification, I was just pointing out that this field of
multiplication or
> probability factor could leave lots of flexibility and enhancements
should
> someone try this direction for future research or even proprietary
use.
> We see asymmetry of more than 20db difference on opposite links caused
> by Receiver noises and Transmitter loads, so unlike the wireless media
- for
> us the assumption that a opposite link exists when receiving a DIO
cannot be
> implicit in many cases. Loosing the link with a parent from the parent
set
> without the parent loosing the link with the child is common and doing
lots of
> pings is a waste. So having a DIS/DIO session occasionally would
really help to
> quickly find alternate parents+update rank, and filtering DIO
responses
> would also help in these cases.
receiving
> the DIS packet follows the critical MUST path of RPL? <</yoav>>
> 
skeptical.

---

From: Nicolas DEJEAN <[email-masked]>
Date: Fri, 16 Apr 2010 21:47:43 +0200

Hi all,

I would like to study this topic on the use case point of view.

Thank you for reading.

Nicolas.

===============================================================================================

Importance of the bottom-up connection method:
---------------------------------------------------------------------

According to my understanding of RPL, it seems that an orphan router
that wants to join a network without waiting for potentially late DIO
should do the following:
- optionally sending a DIS for quick connection,
- interpretation of DIOs obtained in response for parent(s) selection,
- optionally DAO generation for becoming a destination.

 According to my experience in metering network:
- some known cases require a bottom-up installation:
    - punctually adding new endpoints (local extension) or replacing
endpoints (maintenance) in an existing and well working network,
    - add a complete new application in an existing and well working
network (for instance, an electricity metering network has been
deployed and it is now expected to connect water/gas meters to the
electricity meters)
- a utility technician wants to connect its equipment and be sure that
it is really connected in a reasonable time and often in the shortest
possible time (1 minute = 1 euro !)

 In this case, it seems really important for this kind of applications
to have an efficient connection process bottom-up.

Parameterization of the Trickle Timer:
-----------------------------------------------------

For reaching expected battery lifetime on both battery-operated
routers and endpoints, the parameters of the Trickle Timer should be
set in a way that ensures low energy loss even when running at its
minimum period.
- Otherwise, the cost of a single endpoint connection could be
dramatic as it resets the Trickle Timer of all the devices in its RF
range, triggering extra transmissions and overhearing.
- If we consider an installation session that lasts several days, that
also means that potentially, the routers in the area of the considered
DODAG would reset their timer interval to  the minimal period many
times for several days.

So, on the one hand, we need a short term mechanism for quick
installation processes, and on the other hand we want to have the
Trickle Timer as relaxed as possible for reaching the expected battery
lifetime of the installed devices.

For instance, a parameterization of the Trickle Timer could be:
- min period = 1 hour,
- max period = 1 day (or even a few days)

 As the initial goal of the Trickle Timer is to provide a smart
consistency maintenance mechanism through the network, which it does
perfectly, we can conclude that we need another mechanism for reaching
the second requirement of this class of applications, i.e. a quick
connection process.

Quick connection process proposal:
---------------------------------------------------

In a general manner, I fully agree with most of the proposals of
Phoebus and Pascal in the current thread:
- Do not link the reset of the Trickle Timer with the method of
transmission of DIS (unicast/multicast) but instead use a flag for
that purpose:
    - http://www.ietf.org/mail-archive/web/roll/current/msg03570.html
    - http://www.ietf.org/mail-archive/web/roll/current/msg03571.html
    - http://www.ietf.org/mail-archive/web/roll/current/msg03590.html
    - http://www.ietf.org/mail-archive/web/roll/current/msg03604.html
- Avoid making the Trickle Timer much more than it was originally
designed to do:
    - http://www.ietf.org/mail-archive/web/roll/current/msg03600.html
- Find a way to avoid restarting the exponential backoff game from start:
    - http://www.ietf.org/mail-archive/web/roll/current/msg03630.html

I would even go a little bit further by saying that the mode used for
sending DIOs  (unicast/multicast) should also be dictated by a U flag
contained in the DIS, but let us see why later.

 The idea is to propose a way to achieve a quick connection to the
network without resetting the Trickle Timer of all the answering nodes
as the insertion of a new node should not be systematically detected
as an inconsistency.

 I think the following mechanism could allow reaching this double goal:
- A DIS message can be sent in multicast mode without setting the C/R
flag (reset Trickle Timer), because this DIS does not imply
inconsistency.
- The optional usage of some filters contained in the DIS message
could allow only a subset of the receivers to answer, thus drastically
reducing the 1-hop storm possibility.
- In this case all answering nodes should answer as immediately as
possible in unicast mode to the DIS originator. If multicast mode is
used for DIOs in this case, some inconsistency might be detected at an
unexpected instant as a simple connection of a new device to the
network could trigger a control traffic storm:
    - If filters are used in the DIS, we can expect that the MAC Layer
will be able to deal  with this controlled answer storm
    - If no filter is used, the answering node should set up a
temporary shorter exponential window based on the Trickle Timer
configured with specific parameters (that could be passed into the DIS
request). The Trickle Timer is then configured back with its default
parameters after the DIOs wave. The expected DIOs wave duration could
also be a parameter of the DIS in this case, which would mean
something like: I will listen for DIOs for XX seconds for instance.

Please, note that (according to my knowledge of the draft) this
specific mechanism does not go against any of the other mechanisms
already described.

 This is simply a new usage case which is triggered by a DIS sent:
- multicast,
- without Reset Trickle flag set.

Then the receivers of the DIS simply answer almost immediately and do
not modify their background activity in the existing and well-working
network which allows reaching the initial double goal of:
- providing a quick connection process,
- without changing the background activity of the existing and
well-working network, thus avoiding any energy loss.

 A cleaner alternative would be to use an additional flag requesting
the DIOs to be sent in unicast mode. Let us call it the U flag which
triggers multicast DIOs when reset and unicast DIOs when set.

The considered DIS message would then have the following specificities:
- sent in multicast mode,
- C/R flag is reset,
- U flag is set,
- Optionally it could embed (to be defined later):
    - Temporary Trickle Timer parameters,
    - Expected DIOs wave duration,
    - Smart filters for reducing the number of triggered DIOs

===============================================================================================