Re: [core] #177: Response suppression for multicast not defined

What is not explicit in core-coap is how a CoAP proxy sends multicast responses back to a client (that used the Proxy-URI option), and hence what a client should expect to get back from the proxy. Maybe the general idea is obvious: proxy does not perform any processing/filtering/aggregation but sends back the individual responses to the client.

One remaining question; what if a client sends a unicast CON request to a CoAP proxy containing the Proxy-URI option, and then receives from the proxy multiple responses resulting from the CoAP multicast. Would it get NON responses from the proxy, or CON, or is that up to the implementation? NON would be preferable for congestion control reasons but this is not explicitly mandated by core-coap. CON would be logical if the aim of the proxy is to reply CON to a CON proxy-request following section 5.2.3. It could also be left as an implementation decision. (Without any extra guiding text, my guess would be that it becomes implementation-specific behaviour.)

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Wednesday 14 March 2012 20:07
To: Rahman, Akbar
Cc: core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

> Thanks, I read coap-09 and saw the new text for multicast response
> handling in section 4.5.  One follow up question:
>
>
> - If the multicast message receivers (servers) do send back valid
> responses (e.g. successful Response to a GET), then the original sender
> (or some intermediate CoAP proxy) will receive multiple responses and
> will have to some method of filtering and processing the multiple
> responses.

That is the nature of multicast, so I would expect the need for that to be obvious.
We do not specify local processing, so what exactly the client does with the information is up to the implementer.

> - We show one possible use case in
>
> http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17

Indeed, but generally the core-coap draft is very sparse on use cases.

> - Should we have some text in coap-09 to cover this multiple response
> processing as well?

So, in summary, I do not see a need for additions to core-coap.

Grüße, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.