Subject: [core] CoAP 04 Feedback

From: Guido Moritz <[email-masked]>
Date: Tue, 25 Jan 2011 10:57:37 +0100

Dear authors,

I am happy to see CoAP-04 out and it seems in a good shape...thanks for the
authors and the work they have done!

Nevertheless, some critical points:
1) Own Options
I would be interested in more details how to proceed with own CoAP options
as it is mentioned in 04 briefly only. What made HTTP applicable in several
of applications is the extendibility of the header with own fields. But
since CoAP is binary, overlapping header definitions might become a serious
problem (I have in mind huge networks running CoAP requiring several
different extensions). What is the plan to prevent this? Do I need to go
through IANA each time?

2) Ignore Duplicates
I know that there has been a similar discussion, but I would be happy if
there is a more clear definition which messages will be ignored. Something
like: "If the same Message ID is received, process only the first one and
ignore the others". Or couple the defined procedure on the used method?!
This is just a question of a clear definition how to implement CoAP.

3) "Empty" messages
I stumbled over the "empty" message in e.g. section 4.3.1 and 4.3.2. It may
be interpreted that "empty" means no payload and thus the mentioned sections
make no sense at all. Maybe a clear definition of an empty message in
section 2.1 would relax this.

4) Response Codes
I don't really like the definition that 2.00 OK is only possible for a GET.
What is the general intention to limit the response codes on single methods,
especially the most generic code 2.00 OK? I have a scenario in mind where a
POST request is processed and may result in a merge of two resources to one.
Hence one is created, two are deleted. I can do this in two or more request,
but I would like to use one. So DELETED and CREATED are not appropriate and
I would like to have an OK by the server if everything is fine...but this
was a POST and not a GET. There may be more scenarios were a simple OK is
the most reasonable response. 

5) Message Size
I still don't like the definition of message size (section 3.1), because it
refers too much to the IP layer and too much to the link layer sizes
(especially in case of CoAP is carried over IPv4). This is a very heavy
cross layering and I am not sure if implementers of applications are always
aware of this and the implications. Additionally I am still not sure about
the term "IP datagram" as "datagram" is defined by ISO as term for transport
layer (i.e. UDP).
Because CoAP is based on UDP, maybe a better definition would be "A CoAP
message MUST fit in a single UDP datagram". 
Additionally there might be separate definitions like: "If running over
IPv4, IP fragmentation MAY be avoided and SHOULD be avoided if carried over
IPv6". This lightens these definitions a bit and especially as IPv4 has (as
far as I know) no clear definition of a minimum MTU like IPv6. Nevertheless
I am not sure why such an IP layer definition is required at all (again as
far as I know IPv6 requires fragmentation as MUST) and it also might be
replaced by "SHOULD not exceed 1280 byte". Such a numerical definition is
much clearer.
(BTW: The definition of a "good upper bound" does not relax the obscurities
in this section)

Mit freundlichen Grüssen

Guido Moritz

-------------------------
Dipl. Ing. Guido Moritz
Universitaet Rostock, Fakultaet f. Informatik und Elektrotechnik
Institut f. Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and Computer Engineering
Richard-Wagner Str. 31, 18119 Rostock-Warnemuende
Phone:  +49 (0)381 498 - 7269
http://www.imd.uni-rostock.de
http://www.ws4d.org
http://www.aal-rostock.de

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jan 2011 12:08:35 +0100

Hi Guido,

thanks for reviewing this draft so quickly.
These are all very good points.

To get some structure into the discussion, let me start with your point 1.
coap-misc (which is very much overtaken now in certain parts and sorely needs to be updated) defines a User-defined option.
Is that something we should pick up?  Or do you have something different in mind?
I think we can discuss this best by first starting with the use case.

Gruesse, Carsten

---

From: Guido Moritz <[email-masked]>
Date: Tue, 25 Jan 2011 13:02:29 +0100

Sorry, I didn't had in mind that misc-06 proposes something like this. What
is required is some kind of "cookbook" or "framework" how to define own
options without requiring going through any registration process. 
I am not completely sure about the use cases. But a view on HTTP and the
existing enhancements (WebDav, XMPP over HTTP, RPC over HTTP, SOAP over
HTTP...) points to a need for such a mechanism to make CoAP not yet another
protocol but a long term cross domain solution. When defining HTTP, surely
nobody had in mind such mentioned couplings. But they are out there and
working...

Misc-06 seems to be a good starting point. Nevertheless, I am not sure if
the SDNV separation is applicable. 
Maybe it would also be possible to have a double-track solution: 
1. Either the own option is identified by a binary encoded option, defined
somewhere at IANA or any other responsible organization (similar to the
solution in misc-06). Can we make sure to have all these registration in one
place to prevent from overlapping? 
2. Or if not applicable or possible, the own option may be identified as
ASCII string carried inline in the header. It is not optimal in size, but
very flexible and eases definition of own options significantly. 

Guido

> -----Ursprüngliche Nachricht-----
> Von: Carsten Bormann [mailto:[email-masked]]
> Gesendet: Dienstag, 25. Januar 2011 12:09
> An: Guido Moritz
> Cc: 'core'
> Betreff: User Option -- Re: [core] CoAP 04 Feedback
> 
> Hi Guido,
> 
> coap-misc (which is very much overtaken now in certain parts and sorely
> needs to be updated) defines a User-defined option.
> Is that something we should pick up?  Or do you have something different
in
> mind?

---

From: [email-masked]
Date: Tue, 25 Jan 2011 16:55:19 +0100

Hi all,

First of all I would like to congratulate the authors for their work.

Here are some more comments about the draft, hoping it could be useful.

1) section 4.1
The text about response floods with error codes has been removed but 
section 10.3.3 and 2.1 still have references to it.
Also there could be an additional congestion control mechanism for 
multicast responses like a short random delay for responses to a multicast 
request.

2) section 5.3
Why is it a SHOULD and not a MUST in the sentence "The client SHOULD 
generate tokens in a way that tokens currently in use are unique"?
For the message ID the equivalent sentence is with a MUST. Is it because 
if the client knows in advance that every transactions are immediate, 
tokens will be useless?

3) section 5.8.2
IMHO the term full deduplication support is not well defined. Maybe there 
could be a separate section to describe the deduplication mechanism and a 
reference in 5.8
The right thing to do with duplicate messages is better expressed in 
coap-4 but is still not obvious because there are many optimizations that 
an implemention may chose to adopt.

4) section 5.10.1
The token option defaults to a zero-length token. What is the exact goal 
for an empty token? Does it mean that a client supporting only one 
outstanding request does not have to generate a token and can just always 
use token 0? Is there a risk to receive cross responses if a client always 
uses the same token even if there is only one active request at a time and 
especially in case of deferred responses with late retransmissions?
 Maybe there could be a reference to section 5.3 which already contains 
details about empty token.

5) section 5.10.5
I understand the text with the opposite meaning compared to coap-3 when 
max-age is used in a request. What is the exact goal? 
a) I want a representation that I can keep at least X seconds in my cache. 
(coap-4)
b) I want a representation which is no more than X second old. (coap-3)

6) Table 1
- IMHO the explanations in appendix A about zero-length uint for max age 
and URI port appear quite late.
- Table 1 specifies that the length range for the token option is 1-8. It 
is not fully consistent with an empty default value. But maybe it means: 
if the option is present the length is 1-8 otherwise the length is 0

7) section 8.1
The most used HTTP code (200 OK) is the most complex to map to CoAP. Maybe 
a more straightforward mapping could avoid interoperability issues.

8) section 10.3.1
Do you think there is a possibility to build a link-format just like a 
sequence of coap options and then share the same base code but with 
options dedicated to /.well-known/core? URI parsing/construction of coap 
with split paths is much simpler than the current link-format syntax. This 
could reduce the processing vulnerabilities and the amount of code thus 
probably also improve deployment of the discovery feature.

Regards,
Matthieu

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jan 2011 17:58:21 +0100

Hi Matthieu,

another set of high-quality comments.

> if the client knows in advance that every transactions are immediate, 

That is clearly an oversight.
There is one strange corner case, where you have two request going at the same point and don't care which one you get.
Say, there are two sources for some information, and you do a GET of both.
Really a corner case.
In the end, if you don't use unique tokens, you don't know which of your questions were answered.

> for an empty token?

Use very little space :-)

> Does it mean that a client supporting only one 
> use token 0?

Well, the request might be answered with an empty message (i.e., be deferred), and *then* you have to start using other token values if you want to put another request in flight before you got the response (and maybe have waited some suitable MSL to account for UDP duplicates).  As long as all your requests get immediate responses, you can continue to use a default token.  Also, if you never send another request (more precisely: expect to get another response) before you got the deferred response that used up your empty token (and some suitable MSL has elapsed), you also get by with an empty token.

> Is there a risk to receive cross responses if a client always 

The same applies if you always send token 0x4711, so it's not something special about the empty token, it's about token reuse.
Reusing the empty token is just especially attractive, because it needs zero space in both request and response.

> max-age is used in a request. What is the exact goal? 

I don't know; I'm arguing for getting rid of this.

> a) I want a representation that I can keep at least X seconds in my cache. 

Well, that makes at least a little bit of sense, so that's what's in there.

> b) I want a representation which is no more than X second old. (coap-3)

b does not work very well.  Scenario:
C sends a GET/max-age=10 to O, the origin server, and caches the response.
7 seconds later, B does a GET/max-age-10 to intermediary C and caches the response.
6 seconds later, A ends GET/max-age=10 to intermediary B.  
B of course responds out of its cached response, since it got that only 5 seconds ago from C.  
Now A got a message that is 13 seconds old.
We'd need something similar to HTTP's Age: header, or some really complicated rules for tagging cached responses and only using this if there was an appropriate chain of max-age request options, to solve this.  Worth it?  For which scenario?

> probably also improve deployment of the discovery feature.

Interesting.

Gruesse, Carsten