Subject: [core] RE CoAP block use cases (was Re: What's to be presented to IESG in December?)

From: [email-masked]
Date: Tue, 2 Nov 2010 15:58:47 +0100

Hi Peter,

See mvial> comments inline

             Peter Bigot                                                   
             <pab@peoplepowerc                                             
             o.com>                                                      A 
                                       Matthieu                            
             29/10/2010 17:14          Vial/FR/Non/Schneider@Europe        
                                                                        cc 
                                       core <[email-masked]>                
                                                                     Objet 
                                       CoAP block use cases (was Re:       
                                       [core] What's to be presented to    
                                       IESG in December?)                  

                                                                           

On Fri, Oct 29, 2010 at 9:11 AM, <
[email-masked]> wrote:
      >I feel coap-block is unnecessary if one can defer to alternative
      protocols (and we will need Uri-Scheme back to enable that, which I
      very much want) and therefore would not use it myself, but >with a
      change that prevents servers from introducing it in the response when
      Block doesn't appear in the request---and pending a final review---I
      would support it for December.

      I think we should clearly expose the use cases where coap-block would
      be necessary.

Agreed, almost.  Let's expose the use cases where "something like
coap-block" would be necessary.  A quick attempt at "something like"
produced "a client or server cannot transmit or receive a request or
response for a particular resource representation in a single CoAP message
while meeting system quality requirements such as avoiding
link-layer--induced fragmentation", which is just gross regardless of
whether it's accurate.

      I see the following items from the previous emails.
      1) transfer resources larger than the 1280-x limit

There is no 1280-x limit.  The formal limit is the size of an IP datagram.
Any specific numeric limit imposes an assumption of an underlying IP
version and perhaps link technology, which I argued last summer was
inappropriate for CoAP.  We could revisit that position.  But yes, even for
an IP datagram limit, this is a valid use case.

mvial> Agreed, almost. Some constrained devices will probably not support
IP fragmentation.

      2) force small transactions due to limited available RAM for CoAP
      buffers

Yes.  The size-related options proposed too late for inclusion in -03 would
be a good approach to ensure this situation is detected and handled, and
are arguably a MUST for the final version.

      3) semantic segmentation of a large resource to be able to produce
      and consume it incrementally. It also reduces the hardware (RAM, CPU)
      requirements to process the resource.

If there's a semantic segmentation within the resource representation, I
think each segment should be treatable as a distinguished resource.  That
could be as simple as adding a numeric or symbolic component at the end of
the path component of the URI for the the aggregate resource.  Or defining
"first" and "next" keys in a query part and using POST, if you want to
dynamically generate the representation.  Absence of those keys would
require that the entire resource be returned in a single representation,
through whatever mechanism that is done.

mvial> I think that 2) and 3) are highly correlated. Because a device that
can't receive a large content in a single transaction will probably not
have enough memory to reassemble the whole representation split into a
bunch of smaller transactions. Offering an optimized mechanism to produce
and/or consume a large amount of data incrementally will definitely be a
nice feature. I don't know yet if it should be a builtin feature of CoAP or
just recommendations on the design of the API and URIs.
>From your comment I don't get how you can create a linked list of resources
by just adding a symbolic component at the end of the path. You should at
least add a link to the next URI whitin the representation of each resource
which is part of the aggregate.
Always using POST will prevent clients and proxies from caching the
resource. Given the complexity to generate and transfer this kind of
resource it would certainly be valuable to cache it.

      4) optimize link-layer fragmentation and avoid network congestion

How CoAP should accommodate link-layer limits that are smaller than
IP-datagram limits, given that there is no requirement to provide access to
those limits, is an open question.  Again, the size-related options would
at least provide a way for the client and server to negotiate the
transaction limits via application or even CoAP-level configuration.

      Protocols like tftp would probably only solve item 1) and maybe 4)
      within limits.
      Do you think other items are acceptable and need a solution ?

(2) yes, though I don't see why tftp doesn't work there too.  (3) I think
should be solved at the architectural level in the API, not within the
transfer protocol.

For non-semantic segmentation and to enable a coap-only implementation, I
think the block option can be made to work (with that change I mentioned,
and maybe a little more investigation into the impacts of random access
and/or dropped packets in the face of dynamic representation generation).
That I currently believe TFTP is a superior approach for my own systems is
an architectural trade-off based on my strong preference to re-use
existing, proven solutions unless they're clearly inappropriate.

mvial> Neither POST nor caching options are available with TFTP  thus I
don't think it can be considered as the ultimate solution each time a
representation exceeds few link-layer packets. Being able to cache large
resources is very desirable. IMHO CoAP and its extensions (coap-block or
something else) should define a comprehensive protocol that can handle such
a situation while permitting alternative solutions (TFTP, FTP...).

Matthieu

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________