Re: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Imed :

Thanks a bunch for sharing this work.

A bunch of preliminary notes:


-          The number of children is very indirect and thus not a  good representation of the load expressed in terms of packets/ battery consumption. The number of routes via the children is better but it is only known in storing mode; and the real amount of traffic may be what you are probably after; these could be exposed to the children in parent DIOs.

-          Changing routing based on load has been known to cause oscillations; this is to be considered / avoided.

-          One possible angle is to smoothly adapt the load in the forwarding plane as opposed to change the Rank to abruptly. Children with multiple parents could balance their flows based on parent load.

-          We had discussions in the past on the load in storing nodes to avoid having to maintain more routes than the node can actually store in memory. The idea at the time was to answer the DAO-ACK with a status and a metric that would discourage the child, or IOW encourage it to look elsewhere. The benefit of that approach was load balancing (of number of route entries). Problem was still that at some point there could be more routes than the nodes could do with, so people went for non-storing anyway.

-          Changing the DIO in a non-backward-compatible fashion is probably not a good idea. Did you consider options?

-          Section 4 is really hard to read. For the most part I'm still not sure I understood what is meant there. I figured that the design is that children send DIOs so that their parents will know that they are their parents? This is kind of weird since they parents should ignore DIOs with higher Ranks.  Also unsure why DAO or ND cache can't be used, the explanation confused me. In storing mode, parents have adjacencies for their children that inject DAOs, and these can be counted.

Cheers,

Pascal




From: Roll [mailto:[e-mail]] On Behalf Of Romdhani, Imed
Sent: lundi 6 février 2017 14:50
To: [e-mail]
Cc: Al-Dubai, Ahmed <[e-mail]>; Qasem, Mamoun <[e-mail]>; Ghaleb, Barraq <[e-mail]>
Subject: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt

Dear all,

Hope this finds you well.

We would like to draw your attention that we submitted a new draft for you to consider. You can access it from here:
https://www.ietf.org/id/draft-qasem-roll-rpl-load-balancing-00.txt

This draft proposes an extended Objective Function(OF) that balances the number of children nodes for potential overloaded parents to ensure node lifetime maximization in RPL. In addition, a new DODAG Information Object (DIO) message structure has been introduced to record the IPv6 address of the chosen parent before broadcasting the message.

We do believe that the draft is aligned with ROLL's works items and especially with the manageability issue and the need for additional protocol elements to reduce packet size and the amount of required routing states.

We look forward to receiving your comments and feedback.

Kind regards,
Imed
---------------------------------------------------
Imed Romdhani, PhD
IEEE Member, FHEA
Programme Leader of the MSc Advanced Networking
Room C 64
Edinburgh Napier University
School of Computing
10 Colinton Road
Edinburgh, EH10 5DT
UK
E-Mail:   [e-mail]<mailto:[e-mail]>
Home Page: http://www.dcs.napier.ac.uk/~cs244/
Linkedin: http://uk.linkedin.com/in/imedromdhani
Skype: Imed.Romdhani
Telephone: [phone]
Fax: [phone]
---------------------------------------------------


This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373