Subject: [Lwip] draft about implementation techniques for ensuring COAP implementations can sleep

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Jul 2011 16:40:14 +0300

FYI. Comments appreciated.

http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-00

> Filename:	 draft-arkko-core-sleepy-sensors
> Revision:	 00
> Title:		 Implementing Tiny COAP Sensors
> Creation date:	 2011-07-04
>
> Abstract:
>    The authors are developing COAP and IPv6-based sensor networks for
>    environments where lightweight implementations, long battery
>    lifetimes, and minimal management burden are important.  The memo
>    shows how different communication models supported by COAP affect
>    implementation complexity and energy consumption, far more so than
>    mere changes in message syntax.  Our prototype implements a
>    multicast-based IPv6, UDP, COAP, and XML protocol stack in less than
>    50 assembler instructions.  While this extremely minimal
>    implementation is suitable only for limited applications and makes a
>    number of assumptions, the general conclusions point to need for
>    further work in developing the COAP multicast and observation
>    frameworks.
>

---

From: Zhen Cao <[email-masked]>
Date: Wed, 13 Jul 2011 18:50:45 +0800

Hi Jari and authors,

This is draft serves very much for a CoAP implementation guidance.  I
have some questions and comments as below:

Questions: What's kind of tiny devices are you playing with? You
mentioned 32-bit processor, how about the data and code size?  For the
CoAP implementation, is it built on top of some tiny operating system
or stand alone?

Comments:
In Section 4.2, there is a strong message that the CoAP server model
is NOT RECOMMENDED.  It should be discussed though.  In most cases of
the m2m applications and services, it usually is the network side that
initiates the communication and gets some information from the sensor,
and I think that's why CoAP server model seems to be the default model
in draft-ietf-core-coap.  Yes, having the sensor proactively post
information to the server slide is one way to circumvent the sleeping
node issue.   What has been lost here is that the sensor needs to send
the message one by one which is also energy consuming.   In some
implementations, as discussed in section 4.1, a well-known url can be
used, but in many others, the server model is still inevitably used,
where "sleeping compatible protocols" (the term of Margret's position
paper in last IAB IOT Workshop) or always online mechanisms are
expected.

On Mon, Jul 4, 2011 at 9:40 PM, Jari Arkko <[email-masked]> wrote:
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

-- 
Best regards,
Zhen

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Jul 2011 18:20:45 +0300

Zhen,

Thanks for your comments and questions. Inline:

> Questions: What's kind of tiny devices are you playing with?

I'm using MBEDs, ARM Cortex M3 CPUs. But the exact implementation 
platform is not very relevant, I'm playing with a prototype platform 
that I would not use for a real implementation because its too costly, 
power hungry, has too many features, extra interfaces, too big, etc.

> You

The implementation is stand-alone, kind of. It contains everything 
necessary except certain things that I considered to be a part of an 
ideal hardware platform for building sensors.

Other people asked about this as well, so version -01 tries to explain 
this in more detail:

 In this platform, our implementation is under 50 assembler
 instructions (see Note 1).  The implementation consists of a
 Ethernet, IPv6, UDP, COAP, and XML protocol stack and the sensor
 application.  The sensor application is based on values provided by
 an A/D converter; any analog value can be measured.

    Note 1: This contains everything necessary for using an A/D
    converter, constructing a complete Ethernet frame along with the
    higher level protocol fields, and asking the link layer to send
    it.  It excludes platform specific initializations of the link
    layer, actual emitting of bits on the wire, and putting the device
    to sleep and waking it up.  The complexity of these tasks varies
    highly between platforms and link layer technologies.  For
    instance, one some platforms and with Ethernet, sending a frame
    out is merely a question of setting some registers and asking the
    hardware to send a packet.  Of course, with different link layers
    and platforms an implementation might be have to be arbitrarily
    complex to support the intricacies of the link layer in question.

On the prototype platform that I'm using the implementation is big, 
because it links all kinds of debug libraries and other extra things in. 
And there's a separate OS that initializes the system and manages things 
like the USB and flash interfaces.

But these are unnecessary if the implementation was running on a 
production sensor. Lets assume (1) that the CPU needs no particular 
initialization, it just starts executing the program upon wake-up, (2) 
it has lower layer hardware that can be told to transmit an otherwise 
complete frame from the memory in a handful of instructions, and (3) 
putting the device back to sleep is reasonably easy, in the order of few 
instructions. Then we are really talking about an implementation that 
consists of 50 instructions + the few instructions needed for those 
three tasks + data bytes needed for the memory image of the packet, and 
nothing else.

Of course, there are wildly different platforms. I can also imagine a 
sensor that needs a 200.000 line baseband software to manage a 
radio-based link layer.

> in draft-ietf-core-coap. 

Yes, and to be clear Section 4.2 is our recommendation, not the CORE 
working group's recommendation. And we did formulate our recommendation 
in a provocative manner on purpose, to generate some discussion. The 
draft states the reasons for our recommendation, but of course a lot 
depends on what applications one is looking at, what one considers as 
the most important optimization criteria, and so on. So the 
recommendation is just our claim at this stage.

That being said, the CORE working group's model is not cast in stone (or 
an RFC) yet either. Part of the reason that we're bringing these things 
up is that as we have some implementation experience that might help 
adjust the CORE specifications. In general, to me it appears that CORE 
has spent more time focusing on message formats than communication 
models and messaging sequences. Personally, I think message formats are 
less important than the higher level decisions about the communication 
model.

> Yes, having the sensor proactively post
> the message one by one which is also energy consuming.

Not sure what you mean by "one by one", can you clarify?

In any case, there are many different communication models. One approach 
might be to put more intelligence on the sensor so that it reports only 
significant changes, and then you might be able to skip some 
communications altogether.

I should also say that what communication model is best also depends 
highly on how much you think listening consumes power versus sending.

> In some

What we describe in the draft is one extreme approach to sleep 
compatible protocols. We've taken our approach so far that we're 
starting to pay a price, for instance in terms of difficulties for 
ensuring reliable transmission. That being said, I don't think an 
always-on approach is particularly sleep compatible. Maybe there are 
ways to make it more sleep compatible, but again, we should look at what 
those ways are.

Jari

---

From: Zhen Cao <[email-masked]>
Date: Mon, 18 Jul 2011 14:17:50 +0800

Hi Jari,

Thank you for the response.  Please see inline.

On Thu, Jul 14, 2011 at 11:20 PM, Jari Arkko <[email-masked]> wrote:
>
> Of course, there are wildly different platforms. I can also imagine a sensor
> that needs a 200.000 line baseband software to manage a radio-based link
> layer.

Interesting to know your platform.  Thank you.

> Yes, and to be clear Section 4.2 is our recommendation, not the CORE working
> group's recommendation. And we did formulate our recommendation in a
> provocative manner on purpose, to generate some discussion. The draft states
> the reasons for our recommendation, but of course a lot depends on what
> applications one is looking at, what one considers as the most important
> optimization criteria, and so on. So the recommendation is just our claim at
> this stage.

I see.

>
> That being said, the CORE working group's model is not cast in stone (or an
> RFC) yet either. Part of the reason that we're bringing these things up is
> that as we have some implementation experience that might help adjust the
> CORE specifications. In general, to me it appears that CORE has spent more
> time focusing on message formats than communication models and messaging
> sequences. Personally, I think message formats are less important than the
> higher level decisions about the communication model.

Yes, communication model is very important and many times should be
tailored to each implementation model. So I believe this should be in
the scope of LWIG.  Let's discuss it.

> Not sure what you mean by "one by one", can you clarify?

Sorry for the ambiguity.  Assume that hundreds of web users are in
need of the sensor information, so the sensor needs to send to them
one by one, even in the observe model.   I noticed that in your
system, the sensor uses a well-know URL, so that the information is
only sent once. That's a clever way, and releases the need of some
component of coap, e.g., link-format.

> What we describe in the draft is one extreme approach to sleep compatible
> protocols. We've taken our approach so far that we're starting to pay a
> price, for instance in terms of difficulties for ensuring reliable
> transmission. That being said, I don't think an always-on approach is
> particularly sleep compatible. Maybe there are ways to make it more sleep
> compatible, but again, we should look at what those ways are.

Interesting way forward.  Anyway, we will try to take some experience
in our system.   Thank you.

-- 
Best regards,
Zhen