Subject: [core] CoAP and messages sizes

From: Guido Moritz <[email-masked]>
Date: Tue, 14 Dec 2010 17:31:34 +0100

Unfortunately I am only able to follow CoRE in short periods of time in the
last month, so sorry if my questions/comments are again a bit late or even
already solved. 

Because I am trying to put somehow SOAP in resource constrained networks
(e.g. 6LoWPAN networks, please don't hit me for that) I have to work
sometimes with particular huge messages for these devices (up to 5K), if no
compression like EXI is applied.

I assumed that the block option supports both large requests and responses
and I would have been fine with that. But it seems that large messages are
only supported for the response, not for the request. (Sorry, am I wrong
here?) The mailing list argues that most of the scenarios which require
large request are firmware updates and it would be reasonable to use TFTP or
whatever. But CoAP might operate for several years in different domains and
even if we cannot find an application scenario for every requirement, it
wouldn't be bad to thing about from a different perspective.

More specific:
(1) IP packet vs. IP datagram. 
There seems to be a clear difference between these wording as a CoAP packet
SHOULD fit within a packet and MUST fit within a datagram. Sorry, but the
difference is not completely clear to me and after asking several people
around here from different domains, I got 4 different opinions and
definitions (all of them sound reasonable btw). So before I start assuming
what it means, can we clarify the wording please? Thanks.

(2) I would argue that the limitation to fit into a single IP
datagram/packet/whatever is hard to meet, because nobody knows over which
link layer and in which scenarios CoAP is used later on. "Assuming MTU of
1280" is too specific as it assumes IPv6?!
For example, I am using CoAP as lightweight reliable binding for SOAP in
contrast to the unreliable SOAP-over-UDP. This is not restricted to 6LoWPAN
networks and/or IPv6, but might operate also in existing IPv4 networks. And
there is a significant difference in minimum MTU of IPv4 and IPv6. Do we
really want an application designer keeping in mind which IP version and
link layer he/she develops for? Sorry for raising this point again, but my
work is particularly close to the boundaries of message size and I am not
completely happy with the current solution.

(3) The CoAP block option supports only for large Responses, not for
Requests (Right?)
SOAP is one application scenario for messages larger than MTU for both
request and response. Would it be worth finding a more general solution like
the transaction layer also for the large message problem? Maybe CoAP will
not only become a solution for resource constrained networks but also in
common LANs (e.g. Home network) as a reasonable tradeoff between TCP
handshake overhead and unreliable UDP.
A more general solution for both directions would also weaken the long term
significance of (1) and (2). As far as a message is too big, just switch on
the block option for your message and it will work over which IP version and
link layer you want (instead of switching to another protocol which would
require a negotiation mechanism for the used protocol and parameters ...). 

Best,
Guido

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Dec 2010 17:41:50 +0100

> (3) The CoAP block option supports only for large Responses, not for

Right now, -block applies to response bodies in GET, and request bodies in PUT/POST.

(2.2, page 7:)
   In a PUT or POST transfer, the Block option refers to the body in the
   request, i.e., there is no way to perform a block-wise retrieval of
   the body of the response.  Servers that do need to supply large
   bodies in response to PUT/POST SHOULD therefore be employing
   redirects.

In Beijing, we said we didn't really want to add the redirect mechanisms now.
So, as -block is defined now, there is no support for transferring a large response on a PUT or POST.

Gruesse, Carsten

---

From: Guido Moritz <[email-masked]>
Date: Tue, 14 Dec 2010 17:55:48 +0100

OK, thank you for correcting that!

Nevertheless, I would still vote for having block mechanism for both
directions, independent of the method. Supporting large messages is (from my
perspective) an independent feature and should not rely on method or
direction. This would always assum a specific scenario and semantic of the
content of the response on e.g. a GET and not aims at defining a generic
mechanism which is more flexible.

Best,
Guido 

> -----Ursprüngliche Nachricht-----
> Von: Carsten Bormann [mailto:[email-masked]]
> Gesendet: Dienstag, 14. Dezember 2010 17:42
> An: Guido Moritz
> Cc: 'core'
> Betreff: Re: [core] CoAP and messages sizes
>