Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-10.txt

From: [email-masked]
Date: Sun, 26 Apr 2015 23:56:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

        Title           : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control
        Authors         : Anders Brandt
                          Emmanuel Baccelli
                          Robert Cragie
                          Peter van der Stok
	Filename        : draft-ietf-roll-applicability-home-building-10.txt
	Pages           : 32
	Date            : 2015-04-26

Abstract:
   The purpose of this document is to provide guidance in the selection
   and use of protocols from the RPL protocol suite to implement the
   features required for control in building and home environments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joakim Eriksson <[email-masked]>
Date: Mon, 27 Apr 2015 09:09:00 +0200

Hi,

Had a very brief read and have a quick question:

"Packets from asymmetric and/or unstable channels SHOULD be deleted at layer 2."

Do we really mean channel here? asymmetric channel sounds strange - I guess
it should be asymmetric link and/or unstable (high in interference?) channels?

Otherwise I might have missed something in the terminology.

And ETX as the recommended objective function is better than OF0 but
ETX is not giving a good network topology in some cases and since this
is aiming at control I do not think it is the best choice. Interactivity needs
less loss than the objective of being energy efficient.

Best regards,
— Joakim Eriksson, SICS

> On 27 Apr 2015, at 08:56, [email-masked] wrote:
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Wed, 29 Apr 2015 09:26:46 +0200

Hi Joakim,

thanks for your remark.
A channel models the transport through space of e/m waves between two 
interfaces.
An asymmetric channel corresponds with asymmetric transport.

I prefer channel over link, as link usually does not include the concept 
of transport.
I agree that opinions may differ, but the text is clear as it is?

Concerning ETX.
The authors and other people generally recommend ETX. Do you have a 
better proposal backed up by evidence?
I will be happy to hear about it.

Greetings,

peter

Joakim Eriksson schreef op 2015-04-27 09:09:
>>        Title           : Applicability Statement: The use of the RPL 
>> protocol suite in Home Automation and Building Control
>>        Authors         : Anders Brandt
>>                          Emmanuel Baccelli
>>                          Robert Cragie
>>                          Peter van der Stok

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 29 Apr 2015 09:58:14 +0200

Hello!

> On 29 Apr 2015, at 09:26, peter van der Stok <[email-masked]> wrote:
> 
> Hi Joakim,
> 
> thanks for your remark.
> A channel models the transport through space of e/m waves between two interfaces.

Sure, but most of the 6LoWPAN related RFC have been talking about asymmetric links
(look at RFC 6775 - 6LoWPAN-ND as an example). I would suggest keeping the same
terminology since that make things much easier for the reader.

> I prefer channel over link, as link usually does not include the concept of transport.

Well replacing channel would make it a clear text ;-)

> Concerning ETX.
> The authors and other people generally recommend ETX. Do you have a better proposal backed up by evidence?

We have been doing some significant tests and got some good evidence that indicates that picking based on ETX
as is will sometimes cause nodes to pick parents that have crappy links but good rank. We did some experiments that
basically give higher values to retransmissions than transmissions and that is significantly better. Something like

LinkValue = 1 + retransmissions * 3 

instead of 1 + retransmissions * 1.

We have not yet made any RFC or publication on that yet - but we will hopefully get the time to do that
sooner or later (we have seen this in multiple separate projects). ETX is all fine for data collection networks
which is more or less was designed and evaluated for, but not for interactive networks where users expect 
low latency when trying to configure/switch things.

Best regards,
— Joakim Eriksson, SICS