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

["G. Clark" <[e-mail]>]

Hi:

A quick question / comment:

Zach Shelby wrote:
> Andreas,
>
> On Feb 8, 2010, at 18:47 , Andreas Scholz wrote:
>
>   
>> 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.
>>     
>
> Good point. My own assumption is that the reliability feature over UDP can be shut off when not needed. 
>
>   
I did notice that in section 2.8.1 (wrt UDP transport), the draft said: 
"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."  I found this to be a bit confusing, though: how do we meet 
REQ10 without enforcing reliability in requests?
>> 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.
>>     
>
> This is something to consider wrt subscription, I could add some text about that to draft-shelby-6lowapp-coap.
>   
Instead of including TCP / UDP in the subscription request, would it be 
a bad plan to encode reliability in a service's URL?  e.g. 
coap[s]://my.device/reliable/service.  In this way, you could also 
mirror services (coap[s]://my.device/xyz, 
coap[s]://my.device/reliable/xyz) pretty easily.  This does have the 
downside of introducing more overhead, and it wouldn't be practical for 
multiple options to be encoded this way. 

This approach would move the decision for reliable / non-reliable 
transport to the application layer.
>> 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).
>>     
>
> Definitely! 
>
> Zach
>
>   
Regards,
Gilbert Clark
Grad Student
Ohio University
>> Best regards
>>
>> Andreas
>>
>> -- 
>> Andreas Scholz               Lehrstuhl Informatik III
>> Tel. [phone]        TU München, Zimmer 02.11.037 FMI
>> [e-mail]     Boltzmannstr. 3, 85748 Garching
>>
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>>     
>
>