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

From: Peter Bigot <[email-masked]>
Date: Fri, 29 Oct 2010 10:14:48 -0500

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.

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

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

Peter