[core] Comments on draft-shelby-core-coap-req-00.txt

["Bob Dolin" <[e-mail]>]

This didn't appear to go through last night, so I am re-sending. I
apologize in advance if you are receiving this twice.

 

 

Comments on CoAP Requirements and Features,
draft-shelby-core-coap-req-00, 

issued on February 18, 2010.

 

Bob Dolin

Echelon Corporation

 

After reading this document, I have to say that the requirements stated
within it 

are insufficient to serve the markets that my company does. Those
markets are, 

I believe, what the expansion of IP to the "internet of things" is
intended to address. 

Essential to this market is a uniform set of protocol services that
interoperate, to

enable applications to be easily developed with the result that a bunch
of intelligent 

objects, made by different companies, and integrated together by an
unsophisticated user 

work as expected.

 

Below, are some more detailed observations.

 

The document contains the following abstract:

 

Abstract

 

   This document considers the requirements and resulting features

   needed for the design of the Constrained Application Protocol (CoAP).

   Starting from requirements for energy and building automation

   applications, the basic features are identified along with an

   analysis of possible realizations.  The goal of the document is to

   provide a basis for protocol design and related discussion.

 

[bobd] I think this abstract is overly constrained in its scope, or
other

parts of this document far exceed the scope alluded to in the abstract.
It says

that its focus is on energy and building automation applications.
However,

the scope of IP for resource constrained devices, or IP for Smart
Objects

goes well beyond building automation and energy applications to generic

sensing, monitoring and control of "things." I believe that the abstract

should be to support the IP connectivity of smart objects, or something 

like that to encompass the broader "internet of things," or generic M2M 

applications or something along those lines.

 

In the requirements section of the document it says:

 

   REQ9:   CoAP will support a non-reliable multicast message to be sent

           to a group of Devices to manipulate a resource on all the

           Devices simultaneously [charter].  The use of multicast to

           query and advertise descriptions must be supported, along

           with the support of unicast responses

           [I-D.sturek-6lowapp-smartenergy].

 

   REQ11:  Reliability must be possible for application layer messages

           over UDP [I-D.sturek-6lowapp-smartenergy].

 

[bobd] These, along with the attendant features of duplicate packet 

detection, transaction timing, retry counts and retry timers are
transport

layer services and are not part of an application layer protocol. These 

transport layer services should not be forced upon every application
author 

to code up, get right, and interoperate with the other implementations.

Typical application developers have application domain knowledge.
Typical

protocol engineers know about protocols, but do not have application

domain knowledge for every application that may use their protocol. It
is

unreasonable to expect either group to do a good job on the other's area

of expertise.

 

In the general case of IP for smart objects, I would expect (and my
company

has experienced) that developers move applications that were directly
wired,

no network, to one where the I/Os, and controllers are physically
separate and

interconnected with a communication network. In this more general case,
the 

application may be thought of as a single state machine where the
advancement

to the next state is based upon reliable messaging -- if the message
didn't get

there, perhaps a shut down or a safety interlock should be actuated
rather than

just going on. In this environment, reliable unicasting and reliable
multicasting

with duplicate message detection (to support non-idempotent messages)are
required.

Thus, the set of requirements in this draft does not meet the general
requirements 

for creating general, intelligent, distributed applications.

 

Given that features are needed from both a transport and from an
application layer,

the effort should be split into defining a transport protocol for
resource constrained

devices and an application protocol for resource constrained devices.

 

Later on in the document it says:

 

   REQ12:  Latency times should be mimimized of the Home Area Network

           (HAN), and ideally a typical exchange should consist of just

           a single request and a single response message.

           [I-D.sturek-6lowapp-smartenergy]

 

[bobd] One technique to reduce latency is to support multicast
request/response

in the transport layer. It is a slight generalization to reliable
multicast where

a simple acknowledgement is replaced with an application generated
response.

In this way, a single request could be sent to, say 10 nodes, and each
node would

respond, for a total number of messages of 11, versus a unicast to each,
with a 

total number of messages being 20. Multicast request/response service
should be 

required.

 

Further down, the document states:

 

2.8.1.  UDP

 

   The goal of binding CoAP to UDP is to provide the bare minimum

   features for the protocol to operate over UDP, going nowhere near

   trying to re-create the full feature set of TCP.  The bare minimum

   features required would be:

 

   o  Stop-and-wait would be sufficient for reliability.  A simple

      response message itself would suffice as an acknowledgement with

      retransmission support.  Not all requests require reliability,

      thus this should be optional.  Performance is not the key here and

      for more sophisticated reliability and flow control TCP could be

      used.

[bobd] Stop-and-wait is not sufficient for a general purpose application


even in building automation. Consider the case of a node that has as a
primary

responsibility, communicating with some set of other nodes and pinging

them for their application status -- maybe to display on a web page.
Consider

that the set of nodes is large, say 50 or even 100 -- a large building
may

have over 1,000 VAV (variable air volume) controllers in it, so
monitoring

just a hundred nodes is not far-fetched. Now, consider that one node
isn't 

responding. With stop-and-wait, the monitor node cannot move on to ask
the 

next node's status until all the timeouts and retries have been
exhausted on

the first node. Now consider that there is a link failure and multiple
nodes

aren't responding. With only stop-and-wait services, the monitoring
node's 

performance will be unacceptable. Also, I have the same comment that

retries and such are NOT part of the application layer in the ISO model.

 

Next the document says:

 

   o  A sequence number (transaction ID) is needed to match responses to

      open requests and would be generated by the client.  A 12-16 bit

      unsigned interger would be sufficient.  [I-D.frank-6lowapp-chopan]

      also considered this solution.

[bobd] This doesn't belong in an application layer, it is a transport
service.

This seems pretty simple, but what about the error/edge cases, like a
client that

is using sequence number X and has a message outstanding, and then
restarts, and 

issues its next request using sequence number X. Should sequence numbers
be 

persistent across resets, or should one be reserved to only use after a
reset, which

one? What happens when different application developers use different
conventions?

Interoperability can be a real nightmare when such decisions are left to
each 

application implementer. This working group needs to define a distinct
transport

layer and a distinct application layer with well defined services for
each.

 

Next the document says:

 

   o  Multicast support.  Providing reliability with a multicast

      destination address would be very complex.  Therefore the goal is

      to provide a non-reliable multicast service.  In many cases there

      may not be a response to a multicast message.  A multicast command

      might result in an action being taken at a device, but no response

      being sent.  Therefore a multicast request may be answered with a

      unicast response, however without reliability (retransmission

      e.g.).

 

[bobd] I read this as, reliable multicast is really hard, and we need
it, but

since it is really hard, we will define away the requirement, even
though we

need it.  Actually, reliable multicast, reliable request/response, and
multicast

repeated-but-unacked services are all a part of the distinct (as in
separate from

the network layer and application layer) transport layer of ISO/IEC
14908-1, and 

an optimized implementation of that standard fits in 12K bytes for the

MAC through L2 through L7, and consumes only 512 bytes for the RAM. 

So, it doesn't have to be hard or complex, one could simply integrate
what has 

already been done. Granted, in that protocol specification, commonly
called the 

LonWorks(r) protocol or LonTalk(r) protocol, multicast groups cannot be
of arbitrary 

size if reliable services are used, instead the specification does
support groups 

of up to 64 members. The transport protocol itself has no such
limitation. If there

is interest, I could put together an internet draft of such a transport
layer that 

depends only upon the services of an underlying UDP/IPv6 layer.