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

[Zach Shelby <[e-mail]>]

Bob,

Sorry I didn't get back to you earlier. Please see the latest draft just posted where I clarified a couple of the requirements better. I am not able to deal with all of your suggestions as much of this is already from our approved charter, but here are some comments below:

On Mar 23, 2010, at 18:48 , Bob Dolin wrote:

> 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.

Yep, generic M2M is one of the areas taken into account.

>  
> 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].

This is only for unicast UDP, now clarified in -01. In other words, a multicast IP request message may result in a response but we won't try to make that reliable (retransmissions).  

>  
> [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.

This was discussed at length when forming CoRE, and yes some longer-term transport work may get started as a result of our experience here (but that will take years). This WG needs to produce a simple solution using UDP this year. Personally, I don't see a problem of doing a simple stop-and-wait and possible retransmission using UDP. In the future when some better transport becomes available someone can simply define a CoAP binding to that as well. 

>  
> 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.

In the IETF application layer model the transfer protocol and the actual application protocol and logic are two separate things. The goal of CoRE is to define a simple transfer protocol just as HTTP does. The transport area may very well take on some related work in the future, but we can't depend on that. 

>  
> 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.

This is exactly what will be done. When we talk about multicast, it is IP multicast. Therefore a 
multicast message in that case may result in up to 11 messages. So no problem here. If this multicast request needs to be 100% reliable then that needs to be handled by the application protocol using CoAP. 

The text below is no longer in the document, instead we are working on that in the CoAP specification document now.

Regards,
Zach

>  
> 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.
>  
>  
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Head of Research, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]