Subject: [Lwip] The LWIG Challenge

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 03 Jul 2014 10:34:58 +0200

Hi all,

I have read draft-ietf-lwig-cellular-01,
draft-ietf-lwig-energy-efficient-00, and I have worked on the TLS
document myself.

There is a common problem among all these documents: they are confusing
because they have no clear reference point and some of the relevant and
interesting content is not typically part of the IETF work (such as
implementation, and hardware).

Covering the topic in a generic fashion just does not work.

What can be done to provide some useful input to the reader?

I believe at least one thing could be done is to focus on selected,
well-known design patterns. What do I mean by that? Take a look at the
DTLS profile document in DICE (see
http://tools.ietf.org/html/draft-ietf-dice-profile-01#section-3) or at
my presentation at the ACE interim meeting.

I picked one (only one) communication pattern and explained the
assumptions. Then, from there you can give very specific advice about
what to do.

Of course, energy efficiency of network communication is only one small
item developers will care about and energy efficiency is a particularly
hard topic since most of the relevant aspects are outside the scope of
the IETF. The IETF draft format is probably not the right tool to convey
that information either.

Just to give you an idea what practical help with regard to energy
efficiency I would be looking for.

I have a Nordic nRF51822-mKIT board
http://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822-mKIT/(language)/eng-GB

What parameter settings could I pick (that have impact on energy
consumption) using mbed (which provides the OS and the protocol stack)
for a few common Bluetooth Smart deployment scenarios / communication
patterns?

This is obviously nothing you would put in an IETF draft but I fear that
this is the type of info people care about.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 13:07:28 -0400

> Covering the topic in a generic fashion just does not work.

I understand what you are saying, and I think that it plagues all across the
IoT space.

    > for a few common Bluetooth Smart deployment scenarios / communication

what if we turn the question around:
  - what parameters should mbed *provide* in order to in order let energy
  consumption be tuned by protocol users?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Cao, Zhen \(CZ\)" <[email-masked]>
Date: Fri, 4 Jul 2014 17:46:21 +0800

Hi Hannes, 

Thanks a lot for the inputs. I agree with part your options, but not all. 	

The lwig started to work on a general document about lightweight implementation guidance, trying to cover all the topics including 6lowpan/coap/rpl/security. It turned out that the document could not be finished in a timely manner. So the group decided that first of all to work on a terminology document. This document turns to be a hub when people started to think about problems in the constrained network. 

The cellular document was indeed a memo when the authors started to work on communication protocols, the document is very useful for readers and implementers when they approach the problems. The energy efficient document that I was editing is probably too general, that's also my feeling when I was working on it. Trying to find a new way out...

For the Nordic nRF51822-mKIT and things alike, yes, I agree with you that the information about the details of configuration is really useful for the developers but I doubt we doing that in ietf. But how to generalize the problems into the IETF language is a challenge. 

Finally I would like to propose some work items for your consideration and discussion,
- Requirement document for constrained devices (sensors and gateway nodes) w.r.t. the IP layer functionalities. 
- A survey document of constrained device developers (some do that for IPv6), link layer, battery life, applications profiles and etc. 

I believe these documents will have more helpful information for developers and designers. 

Thanks for your input again.

With best regards,
zhen

> -----Original Message-----
> From: Lwip [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, July 03, 2014 4:35 PM
> To: [email-masked]
> Subject: [Lwip] The LWIG Challenge
> 
> Hi all,
> 
> I have read draft-ietf-lwig-cellular-01, draft-ietf-lwig-energy-efficient-00, and I
> have worked on the TLS document myself.
> 
> interesting content is not typically part of the IETF work (such as implementation,
> and hardware).
> 
> I believe at least one thing could be done is to focus on selected, well-known
> design patterns. What do I mean by that? Take a look at the DTLS profile
> document in DICE (see
> http://tools.ietf.org/html/draft-ietf-dice-profile-01#section-3) or at my
> presentation at the ACE interim meeting.
> 
> I picked one (only one) communication pattern and explained the assumptions.
> Then, from there you can give very specific advice about what to do.
> 
> Of course, energy efficiency of network communication is only one small item
> developers will care about and energy efficiency is a particularly hard topic since
> most of the relevant aspects are outside the scope of the IETF. The IETF draft
> format is probably not the right tool to convey that information either.
> 
> Just to give you an idea what practical help with regard to energy efficiency I
> would be looking for.
> 
> consumption) using mbed (which provides the OS and the protocol stack) for a
> few common Bluetooth Smart deployment scenarios / communication patterns?
> 
> This is obviously nothing you would put in an IETF draft but I fear that this is the
> type of info people care about.
> 
> Ciao
> Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Jul 2014 12:17:21 +0200

Hi Cao,

> The cellular document was indeed a memo when the authors started to
> work on communication protocols, the document is very useful for
> readers and implementers when they approach the problems.

What did you learn when you read this document?

> consideration and discussion, 

- Requirement document for constrained
> devices (sensors and gateway nodes) w.r.t. the IP layer
> functionalities.
> - A survey document of constrained device developers
> (some do that for IPv6), link layer, battery life, applications
> profiles and etc.

Could you provide further details about what you think could go into
such documents?

Ciao
Hannes

---

From: "Cao, Zhen \(CZ\)" <[email-masked]>
Date: Fri, 4 Jul 2014 19:30:38 +0800

Hi Hannes,

> What did you learn when you read this document?

At least for example, using of send-only model for sleeping nodes to save energy. Need of eliminating the role or acting as a COAP server or Waiting for COAP observation subscriptions. 

> > - A survey document of constrained device developers (some do that for
> > IPv6), link layer, battery life, applications profiles and etc.
> 
> Could you provide further details about what you think could go into such
> documents?

For the survey, we circulate a survey for set of questions for implementers and have some summary results collected. What kind of devices (battery, chipset, linklayer, radio, apps, transport) they are working on and protocols they are using. Sounds good ?

With best regards,
zhen

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Jul 2014 20:45:08 +0200

Hi Cao,

On 07/04/2014 01:30 PM, Cao, Zhen (CZ) wrote:
> At least for example, using of send-only model for sleeping nodes to
> save energy. Need of eliminating the role or acting as a COAP server
> or Waiting for COAP observation subscriptions.

I think that this issue could be described independent of any radio
technology. At least right now there is nothing in there that makes it
radio technology specific.

I have just submitted an updated version of the IAB Smart Object
Architecture document and included a section on design patterns (see
Section 2 of
http://www.ietf.org/internet-drafts/draft-iab-smart-object-architecture-04.txt).

I am convinced that we need to have stories about the standards we
believe should be used in each of these scenarios. Even for the simplest
scenario (device-to-cloud) we do not yet have a complete story.

If we could produce documents that specifically refer to these scenarios
and discuss a specific concern (such as security or energy efficiency)
that might get us somewhere. For DTLS-based security that's what I am
trying to do, as mentioned at the last IETF meeting. I am not yet there
since I am still getting the "paper-work" done in with the DTLS profile
document in the DICE working group. Note also that the DTLS profile
draft only focuses on the device-to-cloud use case - nothing else (and
that's already complex enough).

Ciao
Hannes