[6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00

[Andreas Scholz <[e-mail]>]

As a short introduction: I am writing my Ph.D. thesis in the area of 
constrained networks for control and automation. So I have a rather 
automation-oriented point of view on the requirements for an application 
protocol.

I have a remark regarding REQ10 in the CoAP draft. It states 
"Reliability must be provided for application layer messages". I am not 
sure that really all application layer messages have to be transmitted 
reliably. Consider for example a temperature sensor that provides 
readings on a frequent basis, e.g., every second. Based on the 
application that uses this data, a loss of a single packet (or even a 
bursty loss of multiple messages) may be tolerable. I am thinking of an 
application that controls a heater, or a monitoring application. In fact 
a retransmission of lost messages might even be a problem if this delays 
the transmission of the newly acquired data values. On the other hand 
there a plenty of messages that have to be transmitted reliably.

I think it is very difficult to find a general set of such requirements 
(and other QoS requirements such as latency etc) that is suitable for 
all applications running in a resource constained network. Because QoS 
requirements are typically application specific, the subscriptions could 
be a good location for specifiying such requirements. I am thinking 
about a subscription mechanism that allows a subscriber to not only 
specify the resource he is interested in, but also additional parameters 
such as reliability. This could also be an interesting way for switching 
between UDP and TCP based communication; a subscriber could specify that 
the data should be delivered via TCP instead of the default transmission 
via UDP.

Based on such a subscription mechanism, a node would also be able to 
reject subscriptions based on the specified non-functional parameters. 
For example because it possesses no protocol that supports reliable 
message transmission, or because it has not enough free memory to 
support an additional reliable connection (which requires storing sent 
messages).


Best regards

Andreas

-- 
Andreas Scholz               Lehrstuhl Informatik III
Tel. [phone]        TU München, Zimmer 02.11.037 FMI
[e-mail]     Boltzmannstr. 3, 85748 Garching