Re: [core] draft-ietf-core-coap-09 - Proxying of multicast requests

["Dijk, Esko" <[e-mail]>]

Suppose a proxy has no knowledge of hosts participating in a multicast group. Then indeed it can't rely on its cached multicast responses alone. I was thinking more about this case and how it can still use cached responses:

 1- proxy caches previous responses to a multicast request
 2- for each new Proxy-Uri multicast request that comes in, it always sends out a CoAP multicast request to the multicast group
   [since there may be new group members that joined meanwhile or ones that did not get the previous request]
 3- proxy caches all incoming responses, possibly overwriting the older stored responses
 4- invalid / expired responses are of course removed from the cache
 5- proxy sends all responses (both cached-still-fresh and 'new') back to the original client.

Here caching helps to get a more complete set of responses: if for some reason 20% of group members don't receive a 2nd multicast request; the proxy may still have valid information in cache about all or most of these 20% nodes which was received during a 1st multicast CoAP request.

Note in the above case an implicit assumption is that a CoAP server, who sends out a cacheable response in response to a multicast request, expects/promises to be part of that multicast group for at least the time (Max-Age) of the response. That could be written explicitly (if we want to say something about caching of responses to multicast requests).

Aren't there 4 cases by the way?

        |  reuse for multicast Y/N
--------+----------------------------
reuse   |   Y/Y         Y/N
for     |
unicast |   N/Y         N/N
Y / N   |

regards
Esko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Angelo P. Castellani
Sent: Thursday 26 April 2012 14:38
To: Carsten Bormann
Cc: Dijk, Esko; [e-mail] WG
Subject: Re: [core] draft-ietf-core-coap-09 - Proxying of multicast requests

On Tue, Apr 17, 2012 at 17:40, Carsten Bormann <[e-mail]> wrote:
> with a special "virtual" critical option "this was a response to multicast"?

How can we reuse this response?

case A) We can use it to respond to successive unicast requests.

Then the cache updates the older entry (if any).

case B) We cannot reuse it to respond to successive unicast requests.

Multicast responses should be cached separately.

###### PROBLEMS WITH CASE B
In case B there is (at least) one issue, which is briefly discussed in
Sec. 4.3.3 of http-mapping I-D
(http://tools.ietf.org/html/draft-castellani-core-http-mapping-03#section-4.3.3).
I synthetize the problem afterwards.

When a new multicast request cames in, generally speaking the proxy
couldn't rely only on cached responses to serve client request, since
multicast group membership could be dynamic, and the cached
representation(s) may represent a subset of the actual group, due to
network loss of the previous request/response exchange.

The proxy can, in general, effectively reuse cached representation(s)
only when it has an updated knowledge of the hosts partecipating to
the multicast group, if something is missing the request should be
repeated anyway.
#######

However if we are satisfied with case A, multicast itself could be a
very interesting approach to update the proxy cache for popular
resources, and could even be paired with Observe to obtain this in a
very efficient way.

Best,
Angelo

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