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

["Qasem, Mamoun" <[e-mail]>]

Hi Jianqiang

Thank you for your email.

The identified problem and the proposed solution in the draft “New Version Notification for draft-hou-roll-rpl-parent-selection-00.txt” both have been already addressed in “draft-qasem-roll-rpl-load-balancing-00.txt”. that’s weird.!!

Just to clarify, the "draft-qasem-roll-rpl-load-balancing-00.txt" is not for the non-storing mode as you highlighted, nor for the storing mode and both in the downward routs. The draft mainly focuses on the upward routes (i.e., while maintaining the DODAG through DIOs).

Regarding the comment that you mentioned, which is raised earlier by Pascal along with a bunch of comments, please check the following link of my reply which is already answered your point as well.
https://mailarchive.ietf.org/arch/msg/roll/NP_BltjVY951-ZhtW4psKBIJW2k

Happy to meet you for further discussion, I’ve just arrived Chicago couple of hours ago :)

Cheers
Mamoun


________________________________
From: houjianqiang [[e-mail]]
Sent: Monday, March 20, 2017 12:46 PM
To: Qasem, Mamoun; [e-mail]
Subject: Re: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt

Hi Mamoun,

Your draft “draft-qasem-roll-rpl-load-balancing-00” gives a good idea of the load balancing in the non-storing mode. Like Pascal said the idea is a bit weird, but interesting, promising and there is room for improvement. I have one comment:

Leaving the “parent address” between DODAGID and Option field costs too much, and is not always useful. I think “Parent Address” can be put in the DIO Option field and treated as an optional functionality. What about putting the compressed parent address in the DAG Metric Container? In this way, with a controlled precedence, it can be used with other metrics such as ETX.

BTW, my draft “draft-hou-roll-rpl-parent-selection-00” points to the similar issue but in the storing mode. In the storing mode, nodes are able to count the number of their child nodes, so I put the Child Node Count in the metric container. You may have interest to read it. Hope we can talk face to face in the coming meeting.

Best regards,
Jianqiang



From: Roll [mailto:[e-mail]] On Behalf Of Romdhani, Imed
Sent: lundi 6 février 2017 14:50
To: [e-mail]<mailto:[e-mail]>
Cc: Al-Dubai, Ahmed <[e-mail]<mailto:[e-mail]>>; Qasem, Mamoun <[e-mail]<mailto:[e-mail]>>; Ghaleb, Barraq <[e-mail]<mailto:[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