Opened 11 years ago

Closed 11 years ago

#177 closed protocol defect (fixed)

Response suppression for multicast not defined

Reported by: cabo@… Owned by: draft-ietf-core-coap@…
Priority: major Milestone:
Component: coap Version:
Severity: Active WG Document Keywords:
Cc:

Description

Matthieu Vial reports:

In section 4.1 multicast of coap 03 there is a proposition to eliminate
responses with an error code

This text has been removed in 07 and the text "SHOULD be a Non-confirmable
request" is now a "MUST be Non-confirmable request".
But as I understand coap 07 it is possible to send a response with an
error code to a NON request as a NON response.
So I think the text in coap 03 is now missing to avoid response floods.

Carsten Bormann replies:

indeed, as we fixed the layering here, we lost this functionality.

So what the text in 07 says is that multicast needs to be NON, not CON.
This is at the reliability layer.

The error code becomes visible at the request/response layer.
Independent of whether the request is a NON or a CON, if it does arrive, the server normally will send a response.
1) It is up to the server to decide whether the response is sent in a CON, piggy-backed in an ACK (only applicable to CON requests, which we just excluded), or in a NON.
2) We need to describe what the expectations are when a server does not send a response at all. I think the server should always send a response for a request that arrived via a CON. However, for a NON-request, it might as well pretend it never got the request. This is a bit of a layer violation, as the reliability layer would indicate to the request/response layer wether the request was a NON and whether it came in by multicast.

So yes, I think there should be new text in 4.4 that says the reliability layer does indicate to the r/r layer that this was a multicast. There also should be text, probably in 5.2.3, that restores some form of silent behavior for requests that are "not applicable". This needs to be defined a bit better, I think (even an empty 2.04 might qualify for a "not applicable" here, say in a link-format request with a query. Note that section 4.1 of draft-ietf-core-link-format-07.txt also has something to say about multicast.

Change History (1)

comment:1 Changed 11 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [524]:

Fix #177

Note: See TracTickets for help on using tickets.