Subject: [Roll] The word Up!

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Apr 2010 19:28:44 +0200

I have a _very_ hard time grasping the redefinition of the simple word "up":

> Up:   Up refers to the direction from leaf nodes towards DODAG roots,
> following the orientation of the edges within the DODAG.

Redefinition of such a simple word is very dangerous because it easily
leads to misunderstandings, like this one:

> Movement entails changes to the DODAG parent set.  Moving up does not
> present the risk to create a loop but moving down might, so that
> operation is subject to additional constraints.

Moving "up" what?? (I suppose packets to move "up", but not nodes to 
move "up").

> except in the case where it is intended for the packet to change
> from an up to an down flow

Packets shouldn't change whatever we do.  Or maybe I don't understand
"up" and "down".

Alex

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 9 Apr 2010 10:41:21 -0700

Hi!

It might not be common but it is understandable. 

On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:

> Moving "up" what?? (I suppose packets to move "up", but not nodes to move "up").
> 

Since 'upwards' is the direction from leaf to root, moving up will indicate that a node's rank is decreasing. Obviously this will not cause loops.

> Packets shouldn't change whatever we do.  Or maybe I don't understand

Think of this case you're packets are headed to a node that is in your own subtree. However, you are not a storing node so all your point to point traffic will first traverse the root (or some other storing node if we assume that we still have 'mixed mode which was the case when this draft was written). Going 'up' the root is definitely an upwards flow but it will have to switch to a 'downwards flow'.

Better?

-John

> Alex
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
> 

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Apr 2010 19:54:16 +0200

Le 09/04/2010 19:41, JeongGil Ko (John) a écrit :
>>> Up:   Up refers to the direction from leaf nodes towards DODAG
>>> roots, following the orientation of the edges within the DODAG.
>>
>> Redefinition of such a simple word is very dangerous because it
>> easily leads to misunderstandings, like this one:
>>
>>> Movement entails changes to the DODAG parent set.  Moving up does
>>> not present the risk to create a loop but moving down might, so
>>> that operation is subject to additional constraints.
>>
> Since 'upwards' is the direction from leaf to root,

Who moves "up"?  A packet or a node?

What becomes "up" when leaf and root move and substitute each other?

> moving up will indicate that a node's rank is decreasing. Obviously
> this will not cause loops.
>
>> Packets shouldn't change whatever we do.  Or maybe I don't
>> understand "up" and "down".
>>
>
> Think of this case you're packets are headed to a node that is in
> your own subtree.

Trees?  YEs, please call them trees.  Why explaining in terms of trees
and writing in terms of graphs.

Trees don't have this problem of edges being arrowed.

> However, you are not a storing node so all your point to point

Point to point?  But I thought it was Acyclic?  Which point to which
point?  Or do we tolerate cycles on a single link?

Alex

> traffic will first traverse the root (or some other storing node if
> we assume that we still have 'mixed mode which was the case when this
> draft was written). Going 'up' the root is definitely an upwards flow
> but it will have to switch to a 'downwards flow'.
>
> Better?
>
> -John
>
>> Alex
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>
> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>
>

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 9 Apr 2010 11:07:41 -0700

> What becomes "up" when leaf and root move and substitute each other?

'Movement' here should indicate changes in the rank values of a node. This can be reflected as a change in topology, thus 'movement' in the DODAG :) I think there was some discussion on the list sometime ago on clarifying the term movement. 

> Trees don't have this problem of edges being arrowed.

I should have used subgraph instead of subtree. Sorry for the complication here. 

> point?  Or do we tolerate cycles on a single link?

A link can still be bidirectional. Check out the below topology and the two cases that I describe below.

            Root
           /     \
         A        B
        /
       C

1) If A tries to send a packet to B then it will go 'up' to the root and 'down' from the root to B. 

2) Assuming that A does not have storing capabilities and A wants to send a packet to C, one way of reaching C is by sending its packets 'up' to the root, let the root figure out that the route to C is "root->A->C", then pass the packet 'down' to A then let A pass it to C (using source routing). It's not a loop (so it is acyclic) but they are bidirectional links. That's why we have bits like the 'O bit' to distinguish different types of traffic. 

John

------
JeongGil Ko (John)
Ph.D. Student

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 00:21:55 +0200

Le 09/04/2010 20:07, JeongGil Ko (John) a écrit :

>>>>> Up:   Up refers to the direction from leaf nodes towards
>>>>> DODAG roots, following the orientation of the edges within
>>>>> the DODAG.
>>>>
>>>>> Movement entails changes to the DODAG parent set.  Moving up
>>>>> does not present the risk to create a loop but moving down
>>>>> might, so that operation is subject to additional
>>>>> constraints.
>>>>
> 'Movement' here should indicate changes in the rank values of a
> node. This can be reflected as a change in topology, thus 'movement'
> in the DODAG :) I think there was some discussion on the list
> sometime ago on clarifying the term movement.

I think the draft uses the term "move" to indicate various things
which some times are _node_ movement other times _packet_ movement.

e.g. node movement:
> Movement entails changes to the DODAG parent set.
[...]
> When a node moves to improve its position

e.g. packet movement:
> o A DODAG parent forwards a packet intended to move up,

Additionally, whenever text tries to control physical movement on the
node I think the Author had a difficult to understand mindset:

[...]
> In order to limit erratic movements, and all metrics being equal,
> nodes SHOULD keep their previous selection.

One can't limit erratic movements, nodes move as they please.

> movement within the DODAG are restricted in favor of loop avoidance.

Again, knowing one can't restrict node movement - this reads as if
Author wished to restrict movement of a data structure - is it a
representation of a node in that data structure which moves?

> 5.3.3.4. Rank and Movement within a DODAG Iteration
>
> 1.  A node MUST NOT advertise a rank less than or equal to any
> member of its parent set within the DODAG Iteration.

Does Author intend to limit the contents of the packet the node sends?
(and not the node movement?).

> o  Move down within the DODAG iteration (i.e. increase its rank)

...i.e. sending a _packet_ with an increased rank?

> If a node is allowed to be greedy and attempts to move deeper

(greedier would read as move higher, closer to the Parent, smaller
  Rank, and not deeper bigger Rank).

> If a node needs to move down a DODAG that it is attached to, causing
> the rank to increase, then it MAY poison its routes and delay before
> moving as described in Section 5.3.3.5.

Again, can't tell a node to delay its physical movement. It may delay
sending packets, but not its physical movement. Spec can't pupetteer
nodes if I can say so.

>>> moving up will indicate that a node's rank is decreasing.
>>> Obviously this will not cause loops.
>>>
>>>>> except in the case where it is intended for the packet to
>>>>> change from an up to an down flow
>>>>
>> Trees?  YEs, please call them trees.  Why explaining in terms of
>> trees and writing in terms of graphs.
>>

What's a subgraph? I think we have a clear view of a tree but a subgraph
not...

>> Point to point?  But I thought it was Acyclic?  Which point to
>> which point?  Or do we tolerate cycles on a single link?
>>
>

Ok, but this has nothing of a DAG, it's a pure rectilinear topology,
which, additionally - has 2 interfaces per node! (limited features per 
node right?).

DAGs have arrows on their edges. These arrows must mean something.  If I
want to translate such an arrow in terms of entries in the routing table
then I imply there must be arrows in both directions (there are
routes both ways).  And if I put both arrows on every link then I 
obviously no longer talk DAG...

I don't understand the use of this DAG term overall. I find it an
unnecessary complication.

> and 'down' from the root to B.

I agree, but where else could it go?

Did Author intend to talk about Default routes instead of "Up"? If yes
then why don't we talk Default route throughout? It would be much more
meaningful to me.

> 2) Assuming that A does not have storing capabilities and A wants to
> send a packet to C, one way of reaching C is by sending its packets
> 'up' to the root, let the root figure out that the route to C is
> "root->A->C", then pass the packet 'down' to A then let A pass it to
> C (using source routing). It's not a loop (so it is acyclic) but
> they are bidirectional links. That's why we have bits like the 'O
> bit' to distinguish different types of traffic.

John - loops may form in an acyclic graph painted as above. Suffices it
for Root to forward packets back to A because it had the wrong route.

The image that each node has about the network could be qualified as a
DAG (if one absolutely wishes) but the topology of the nodes is an
arbitrary graph with arbitrary physical node movements.  Mixind the two 
is little understandable.

I think the mindset of designing the protocol should change from one 
where a God-like all-knowing central point dictates node behaviour to a 
mindset where limits are reckoned and well defined, if I can say so.

Respectfully,

Alex

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 9 Apr 2010 15:51:01 -0700

A lot of points here so let me just try to summarize instead of putting things in line.

1. The authors of the draft can better answer this but I don't think the RPL draft even considers physical movements of nodes. This (as far as I know) is out of the scope of what RPL is trying to do. We are dealing with a physically stationary network (no node mobility) and the movements of nodes just indicate the changes in the rank values. So no 'restriction' of physical movement here.

2. I agree with you that some parts use 'move' for node level rank changes and some parts use 'move' for packet exchanges and you pointed out the parts correctly. But I don't think this is so complex that one cannot understand what the draft is trying to say. Still, this is a room for improvement in the draft.

3. For point to point traffic all the discussions until now have shown that we can EITHER have a 'God-like all knowing' central node (as you put it) OR nodes can separately save prefixes in their sub-graphs. No need to change mindsets since here we just support different modes.

4. If you assure that packets with the 'O bit' set to 0 will travel 'up' (to lower rank nodes) and packets with 'O bit' set to 1 will travel 'down' (to higher rank nodes) there should not be a loop formed (at least theoretically). For the cases that the theory fails (crazy things can happen), packets being forwarded must be checked if the forwarding of the packet is valid or not (specs explicitly give you things to check before forwarding a packet). There are also cases where the packets can travel to siblings that can cause loops but RPL limits the number of hops in such cases so that the hop limit exceeds its threshold or an inconsistency is detected if more than two siblings are used for packet forwarding consecutively. 

5. To my understanding (authors can correct me if I am wrong), the DODAG (yes, the DAG) is 'directed' towards the root. So you are definitely right about that. The links that make up the DODAG are selected via DIO exchanges and the rank computation process. RPL just uses the bi-directional connectivity of wireless links (that nodes get anyway) to perform other operations such as point to multipoint and point to point. How do we select the links that are 'directed' to individual nodes (other than the root)? Now that's a totally new story that is still under discussion on the list ;) My example below was a single case where source routing is used and the network has a 'God-like all knowing' root node :)

-John

On Apr 9, 2010, at 3:21 PM, Alexandru Petrescu wrote:

> which, additionally - has 2 interfaces per node! (limited features per node right?).
> 
> routes both ways).  And if I put both arrows on every link then I obviously no longer talk DAG...
> 
> arbitrary graph with arbitrary physical node movements.  Mixind the two is little understandable.
> 
> I think the mindset of designing the protocol should change from one where a God-like all-knowing central point dictates node behaviour to a mindset where limits are reckoned and well defined, if I can say so.
> 
> Respectfully,
> 
> Alex
> 

------
JeongGil Ko (John)
Ph.D. Student

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 01:26:05 +0200

Le 10/04/2010 00:51, JeongGil Ko (John) a écrit :
> 1. The authors of the draft can better answer this but I don't think
> the RPL draft even considers physical movements of nodes.

Physical movements of nodes is in the RoLL requirements!

> This (as far as I know) is out of the scope of what RPL is trying to
> do. We are dealing with a physically stationary network (no node
> mobility) and the movements of nodes just indicate the changes in the
> rank values. So no 'restriction' of physical movement here.

This is a complete misunderstanding.  I am not sure on whom part.
Smiley.  RFC5826 to cite one has a section on mobility.

If the nodes are fixed and don't move then why does the RPL say at 
several points prevent "movements"?  Is this a spec about moving data 
structures in graphs?  IF so then it's wrong, the spec should specify 
how the routers build their loop-free data structures.  No other routing 
protocol does.

> 2. I agree with you that some parts use 'move' for node level rank
> changes and some parts use 'move' for packet exchanges and you
> pointed out the parts correctly. But I don't think this is so
> complex that one cannot understand what the draft is trying to say.
> Still, this is a room for improvement in the draft.
>
> 3. For point to point traffic all the discussions until now have
> shown that we can EITHER have a 'God-like all knowing' central node
> (as you put it) OR nodes can separately save prefixes in their
> sub-graphs. No need to change mindsets since here we just support
> different modes.
>
> 4. If you assure that packets with the 'O bit' set to 0 will travel
> 'up' (to lower rank nodes) and packets with 'O bit' set to 1 will
> travel 'down' (to higher rank nodes) there should not be a loop
> formed (at least theoretically).

This is a wrong mindset on somebody's part.  Smiley.

Loops can form up-down-up-down.

> For the cases that the theory fails (crazy things can happen),
> packets being forwarded must be checked if the forwarding of the
> packet is valid or not (specs explicitly give you things to check
> before forwarding a packet).

I am not in synch with you about what it means to forward a packet.  To
me the only thing a router must check before forwarding a packet are
actually three: the dst field, the Hop Limit and the size.  No more no 
less, shouldn't modify that rule otherwise node can't connect to the 
Internet.

The RPL spec should not check more than these.  If anything wrong in 
these fields then Router should use ICMP to inform the owner of the src 
field about wrong stuff, or hold on for a while and generate new packets 
for establishing routes.  It's as simple as that.

> There are also cases where the packets can travel to siblings that
> can cause loops but RPL limits the number of hops in such cases so
> that the hop limit exceeds its threshold or an inconsistency is
> detected if more than two siblings are used for packet forwarding
> consecutively.

How?  By modifying the Flow Label?  That shouldn't be done.

> 5. To my understanding (authors can correct me if I am wrong), the
> DODAG (yes, the DAG) is 'directed' towards the root. So you are
> definitely right about that. The links that make up the DODAG are
> selected via DIO exchanges and the rank computation process.

That computation process should be left out of this document.

Why don't Authors use the existing methods for this?  Bellman-Ford 
Dijkstra guaranteed bullet-proof Internet scale.

Alex

  RPL
> just uses the bi-directional connectivity of wireless links (that
> nodes get anyway) to perform other operations such as point to
> multipoint and point to point. How do we select the links that are
> 'directed' to individual nodes (other than the root)? Now that's a
> totally new story that is still under discussion on the list ;) My
> example below was a single case where source routing is used and the
> network has a 'God-like all knowing' root node :)

>>>>>>>  DODAG roots, following the orientation of the edges
>>>>>>> within the DODAG.
>>>>>>
>>>>>> Redefinition of such a simple word is very dangerous
>>>>>> because it easily leads to misunderstandings, like this
>>>>>> one:
>>>>>>
>>>>>>> Moving up does not present the risk to create a loop but
>>>>>>> moving down might, so that operation is subject to
>>>>>>> additional constraints.
>>>>>>
>>> node. This can be reflected as a change in topology, thus
>>> 'movement' in the DODAG :) I think there was some discussion on
>>> the list sometime ago on clarifying the term movement.
>>
>> Additionally, whenever text tries to control physical movement on
>> the node I think the Author had a difficult to understand mindset:
>>
>> [...]
>> Does Author intend to limit the contents of the packet the node
>> sends? (and not the node movement?).
>>
>>> If a node needs to move down a DODAG that it is attached to,
>>> causing the rank to increase, then it MAY poison its routes and
>>> delay before moving as described in Section 5.3.3.5.
>>
>> Again, can't tell a node to delay its physical movement. It may
>> delay sending packets, but not its physical movement. Spec can't
>> pupetteer nodes if I can say so.
>>
>>>>> Think of this case you're packets are headed to a node that
>>>>> is in your own subtree.
>>>>
>>>> Trees?  YEs, please call them trees.  Why explaining in terms
>>>> of trees and writing in terms of graphs.
>>>>
>> What's a subgraph? I think we have a clear view of a tree but a
>> subgraph not...
>>
>>> Root /     \ A        B / C
>> Ok, but this has nothing of a DAG, it's a pure rectilinear
>> topology, which, additionally - has 2 interfaces per node!
>> (limited features per node right?).
>>
>> DAGs have arrows on their edges. These arrows must mean something.
>> If I want to translate such an arrow in terms of entries in the
>> routing table then I imply there must be arrows in both directions
>> (there are routes both ways).  And if I put both arrows on every
>> link then I obviously no longer talk DAG...
>>
>> Did Author intend to talk about Default routes instead of "Up"? If
>> yes then why don't we talk Default route throughout? It would be
>> much more meaningful to me.
>>
>>> 2) Assuming that A does not have storing capabilities and A
>>> wants to send a packet to C, one way of reaching C is by sending
>>> its packets 'up' to the root, let the root figure out that the
>>> route to C is "root->A->C", then pass the packet 'down' to A then
>>> let A pass it to C (using source routing). It's not a loop (so it
>>> is acyclic) but they are bidirectional links. That's why we have
>>> bits like the 'O bit' to distinguish different types of traffic.
>>
>> John - loops may form in an acyclic graph painted as above.
>> Suffices it for Root to forward packets back to A because it had
>> the wrong route.
>>
>> The image that each node has about the network could be qualified
>> as a DAG (if one absolutely wishes) but the topology of the nodes
>> is an arbitrary graph with arbitrary physical node movements.
>> Mixind the two is little understandable.
>>
>> I think the mindset of designing the protocol should change from
>> one where a God-like all-knowing central point dictates node
>> behaviour to a mindset where limits are reckoned and well defined,
>> if I can say so.
>>
>> Respectfully,
>>
>> Alex
>>
>

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 9 Apr 2010 16:58:08 -0700

On Apr 9, 2010, at 4:26 PM, Alexandru Petrescu wrote:

> If the nodes are fixed and don't move then why does the RPL say at several points prevent "movements"?  Is this a spec about moving data structures in graphs?  IF so then it's wrong, the spec should specify how the routers build their loop-free data structures.  No other routing protocol does.
> 

You got me! Maybe I was misunderstanding the scope of RPL. But I still think that the "movements" that the draft talks about is only DAG connectivity changes (node changing to lower/higher ranks wrt the connectivity conditions or maybe this implies the physical movements as well?). Now you got me confused as well :) The authors should be the ones that can provide answers without any fuss. You and I arguing over what the draft is trying to mean is meaningless at this point without the help of the authors.

> actually three: the dst field, the Hop Limit and the size.  No more no less, shouldn't modify that rule otherwise node can't connect to the Internet.
> 
> The RPL spec should not check more than these.  If anything wrong in these fields then Router should use ICMP to inform the owner of the src field about wrong stuff, or hold on for a while and generate new packets for establishing routes.  It's as simple as that.
> 

Yes. I was talking about the flow label modification. I sent out a question on the mailing list sometime ago about the issues of using the flow label and at that point this issue was still under discussion. I think the authors are already aware of the RFCs that these flow label modifications can violate.

John

> Why don't Authors use the existing methods for this?  Bellman-Ford Dijkstra guaranteed bullet-proof Internet scale.
> 
> Alex
> 
> RPL

------
JeongGil Ko (John)
Ph.D. Student

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 02:11:24 +0200

Le 10/04/2010 01:58, JeongGil Ko (John) a écrit :
>>> 1. The authors of the draft can better answer this but I don't
>>> think the RPL draft even considers physical movements of nodes.
>>
>>> This (as far as I know) is out of the scope of what RPL is trying
>>> to do. We are dealing with a physically stationary network (no
>>> node mobility) and the movements of nodes just indicate the
>>> changes in the rank values. So no 'restriction' of physical
>>> movement here.
>>
>> several points prevent "movements"?  Is this a spec about moving
>> data structures in graphs?  IF so then it's wrong, the spec should
>> specify how the routers build their loop-free data structures.  No
>> other routing protocol does.
>>
>
> You got me! Maybe I was misunderstanding the scope of RPL. But I
> still think that the "movements" that the draft talks about is only
> DAG connectivity changes (node changing to lower/higher ranks wrt the
> connectivity conditions or maybe this implies the physical movements
> as well?). Now you got me confused as well :) The authors should be
> the ones that can provide answers without any fuss. You and I arguing
> over what the draft is trying to mean is meaningless at this point
> without the help of the authors.

Yours and mine interpretations of the draft are needed, because this 
mirrors what people think about it.  The draft does not belong to 
authors it is for everyone else interested in it.  It is a WG item. 
Thanks for your remarks.

>>> 2. I agree with you that some parts use 'move' for node level
>>> rank changes and some parts use 'move' for packet exchanges and
>>> you pointed out the parts correctly. But I don't think this is
>>> so complex that one cannot understand what the draft is trying to
>>> say. Still, this is a room for improvement in the draft.
>>>
>>> shown that we can EITHER have a 'God-like all knowing' central
>>> node (as you put it) OR nodes can separately save prefixes in
>>> their sub-graphs. No need to change mindsets since here we just
>>> support different modes.
>>>
>>> 4. If you assure that packets with the 'O bit' set to 0 will
>>> travel 'up' (to lower rank nodes) and packets with 'O bit' set to
>>> 1 will travel 'down' (to higher rank nodes) there should not be a
>>> loop formed (at least theoretically).
>>
>>> packet is valid or not (specs explicitly give you things to
>>> check before forwarding a packet).
>>
>> I am not in synch with you about what it means to forward a packet.
>> To me the only thing a router must check before forwarding a packet
>> are actually three: the dst field, the Hop Limit and the size.  No
>> more no less, shouldn't modify that rule otherwise node can't
>> connect to the Internet.
>>
>> The RPL spec should not check more than these.  If anything wrong
>> in these fields then Router should use ICMP to inform the owner of
>> the src field about wrong stuff, or hold on for a while and
>> generate new packets for establishing routes.  It's as simple as
>> that.
>>
>>> There are also cases where the packets can travel to siblings
>>> that can cause loops but RPL limits the number of hops in such
>>> cases so that the hop limit exceeds its threshold or an
>>> inconsistency is detected if more than two siblings are used for
>>> packet forwarding consecutively.
>>
> Yes. I was talking about the flow label modification. I sent out a
> question on the mailing list sometime ago about the issues of using
> the flow label and at that point this issue was still under
> discussion. I think the authors are already aware of the RFCs that
> these flow label modifications can violate.

Well that's good then.  Let's hope for the best.  I will wait and see 
how this evolves.

Alex

>
> John
>
>>> 5. To my understanding (authors can correct me if I am wrong),
>>> the DODAG (yes, the DAG) is 'directed' towards the root. So you
>>> are definitely right about that. The links that make up the DODAG
>>> are selected via DIO exchanges and the rank computation process.
>>
>>> just uses the bi-directional connectivity of wireless links
>>> (that nodes get anyway) to perform other operations such as point
>>> to multipoint and point to point. How do we select the links that
>>> are 'directed' to individual nodes (other than the root)? Now
>>> that's a totally new story that is still under discussion on the
>>> list ;) My example below was a single case where source routing
>>> is used and the network has a 'God-like all knowing' root node
>>> :)
>>
>>>
>>> -John
>>>
>>>>>>>>> Up:   Up refers to the direction from leaf nodes
>>>>>>>>> towards DODAG roots, following the orientation of the
>>>>>>>>> edges within the DODAG.
>>>>>>>>
>>>>>>>> because it easily leads to misunderstandings, like
>>>>>>>> this one:
>>>>>>>>
>>>>>>>>> Moving up does not present the risk to create a loop
>>>>>>>>> but moving down might, so that operation is subject
>>>>>>>>> to additional constraints.
>>>>>>>>
>>>>> 'Movement' here should indicate changes in the rank values of
>>>>> a node. This can be reflected as a change in topology, thus
>>>>> 'movement' in the DODAG :) I think there was some discussion
>>>>> on the list sometime ago on clarifying the term movement.
>>>>
>>>> I think the draft uses the term "move" to indicate various
>>>> things which some times are _node_ movement other times
>>>> _packet_ movement.
>>>>
>>>> e.g. node movement:
>>>> Additionally, whenever text tries to control physical movement
>>>> on the node I think the Author had a difficult to understand
>>>> mindset:
>>>>
>>>> [...]
>>>>> In order to limit erratic movements, and all metrics being
>>>>> equal, nodes SHOULD keep their previous selection.
>>>>
>>>> Again, knowing one can't restrict node movement - this reads as
>>>> if Author wished to restrict movement of a data structure - is
>>>> it a representation of a node in that data structure which
>>>> moves?
>>>>
>>>>> 1.  A node MUST NOT advertise a rank less than or equal to
>>>>> any member of its parent set within the DODAG Iteration.
>>>>
>>>> Does Author intend to limit the contents of the packet the
>>>> node sends? (and not the node movement?).
>>>>
>>>> (greedier would read as move higher, closer to the Parent,
>>>> smaller Rank, and not deeper bigger Rank).
>>>>
>>>>> causing the rank to increase, then it MAY poison its routes
>>>>> and delay before moving as described in Section 5.3.3.5.
>>>>
>>>> Again, can't tell a node to delay its physical movement. It
>>>> may delay sending packets, but not its physical movement. Spec
>>>> can't pupetteer nodes if I can say so.
>>>>
>>>>>>> moving up will indicate that a node's rank is
>>>>>>> decreasing. Obviously this will not cause loops.
>>>>>>>
>>>>>>>>> except in the case where it is intended for the
>>>>>>>>> packet to change from an up to an down flow
>>>>>>>>
>>>>>>>> Packets shouldn't change whatever we do.  Or maybe I
>>>>>>>> don't understand "up" and "down".
>>>>>>>>
>>>>>>>
>>>>>>> Think of this case you're packets are headed to a node
>>>>>>> that is in your own subtree.
>>>>>>
>>>>>> Trees?  YEs, please call them trees.  Why explaining in
>>>>>> terms of trees and writing in terms of graphs.
>>>>>>
>>>> What's a subgraph? I think we have a clear view of a tree but
>>>> a subgraph not...
>>>>
>>>>>> Point to point?  But I thought it was Acyclic?  Which point
>>>>>> to which point?  Or do we tolerate cycles on a single
>>>>>> link?
>>>>>>
>>>>>
>>>>> A link can still be bidirectional. Check out the below
>>>>> topology and the two cases that I describe below.
>>>>>
>>>>> Root /     \ A        B / C
>>>>
>>>> DAGs have arrows on their edges. These arrows must mean
>>>> something. If I want to translate such an arrow in terms of
>>>> entries in the routing table then I imply there must be arrows
>>>> in both directions (there are routes both ways).  And if I put
>>>> both arrows on every link then I obviously no longer talk
>>>> DAG...
>>>>
>>>> I don't understand the use of this DAG term overall. I find it
>>>> an unnecessary complication.
>>>>
>>>> Did Author intend to talk about Default routes instead of "Up"?
>>>> If yes then why don't we talk Default route throughout? It
>>>> would be much more meaningful to me.
>>>>
>>>>> wants to send a packet to C, one way of reaching C is by
>>>>> sending its packets 'up' to the root, let the root figure out
>>>>> that the route to C is "root->A->C", then pass the packet
>>>>> 'down' to A then let A pass it to C (using source routing).
>>>>> It's not a loop (so it is acyclic) but they are bidirectional
>>>>> links. That's why we have bits like the 'O bit' to
>>>>> distinguish different types of traffic.
>>>>
>>>> Suffices it for Root to forward packets back to A because it
>>>> had the wrong route.
>>>>
>>>> The image that each node has about the network could be
>>>> qualified as a DAG (if one absolutely wishes) but the topology
>>>> of the nodes is an arbitrary graph with arbitrary physical node
>>>> movements. Mixind the two is little understandable.
>>>>
>>>> I think the mindset of designing the protocol should change
>>>> from one where a God-like all-knowing central point dictates
>>>> node behaviour to a mindset where limits are reckoned and well
>>>> defined, if I can say so.
>>>>
>>>> Respectfully,
>>>>
>>>> Alex
>>>>
>>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2010 20:31:58 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >> the RPL draft even considers physical movements of nodes.

    Alexandru> Physical movements of nodes is in the RoLL requirements!

And, even it it wasn't, the nodes do not need to move for the
connectivity to change.  

<HUMOUR>
Apparently some of the domiciles in which ROLL will given homes are
infested with walking bags of RF-opaque water! And sometimes, the
annoying "users" manipulate things like doors and windows made out of
special RF-opaque low-e glass!!
</HUMOUR>

I suggest that we might want to come up with a different term than
"move" to describe topology changes.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Jorge Amodio <[email-masked]>
Date: Mon, 12 Apr 2010 22:27:19 -0500

> "move" to describe topology changes.

Makes sense.

If you change

           Root
          /     \
        A        B
       /
      C

By  C--A--Root--B, now things move left <-> right, no more up and down.

I believe the whole movement concept is confusing.

My .02
Jorge

---

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

> I believe the whole movement concept is confusing.

What terminology do you think would be better?

The notion of up/down and shallower/deeper are basic terminology in  
tree data structures and algorithms. E.g., depth first search.

"Move" could be "change its position within the DODAG?"

PHil

---

From: Jorge Amodio <[email-masked]>
Date: Mon, 12 Apr 2010 22:59:23 -0500

> What terminology do you think would be better?

Not sure, I've been trying to follow the thread and now I'm lost about
what is moving from where to where and why.

> The notion of up/down and shallower/deeper are basic terminology in tree
> data structures and algorithms. E.g., depth first search.
>

up/down can have many interpretations, ie link up/down,
upstream/dowmstream, so on.

My interpretation (apologies in advance if I'm getting this wrong
since I'm now lost on the discussion) the intent is to find a better
way to describe how a particular node given a specific event, changes
its "position" in the  routing tree hierarchy. Is it that ?

Regards
Jorge