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

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

Zach Shelby wrote:
> Gilbert,
>
> On Feb 13, 2010, at 0:37 , G. Clark wrote:
>
>   
>>> 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?
>>     
>
> The Section 2.8.1 text is correct. It is REQ10 that is a bit misleading. The protocol is required to have a reliability feature, but the application isn't required to use it ;-) I'll update that in the -01 spin (coming this week).
>
>   
Ah hah!  Got it; thanks.
>>>> 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.
>>     
>
> Reliability should be controlled by the application layer originating a message. For TCP/UDP this is simply done with a Socket API. For the UDP reliability feature, this can be a flag in the header of the message, for example an "ACK ME" flag. In that way a resource (URL) is not dependent on the protocol features used to access it. Makes sense? 
>   
It does; thanks!  I'm not sure I completely understand here, though; 
mind clarifying why don't we want a resource to be dependent on protocol 
features?  I can think of a few cases where I'd only want to offer 
access to a service over UDP as opposed to TCP, for example.
> Zach
>   
Thanks,
Gilbert