Re: [core] Aligning groupcomm-proxy and mutlicast-notifications

[Esko Dijk <[e-mail]>]

Hello Christian,

Yes there's some similarity in the options. In draft-groupcomm-proxy only a forward-proxy is considered, which means the client is explicitly aware of the protocol used by the proxy. (Encoded in either the Proxy-Uri or Proxy-Scheme option.)
For this reason there was no need to include scheme information in the Response-Forwarding option as the client would already know this.

In case the scheme information is encoded in a compact form (e.g. a single CBOR uint as in multicast-notifications) it could still be included in the Option format I think, if that would help the alignment and re-use of the Option for multiple use cases.

Reverse proxies might also be considered for groupcomm-proxy; see also Section 8.4 in RFC 8075. Thinking out loud, there could be a proxy server that is designed like this:
* regular resources /resm maps to a multicast CoAP request being executed
* client that invokes a method on /resm without using 'Multicast-Signaling' Option gets an error back and a 'Multicast-Signaling' Option in the response to indicate that this is needed.
* client can invoke a method on /resm with 'Multicast-Signaling' Option to let the proxy work. Multiple responses will come back to the client. 
* the proxy may have selected the multicast group to send to by itself, based on choice of /resm by the client.

Or a variation on above:
* proxy selects the multicast group and resource based on the URI path, i.e. it is embedded in the URI, similar to Section 5 of RFC 8075 .  This can work towards HTTP clients but also towards CoAP clients.  (For the latter: if for some reason they can't use the forward-proxy function of CoAP e.g. because their library / API doesn't support it.)

Esko

-----Original Message-----
From: Christian M. Amsüss <[e-mail]> 
Sent: Tuesday, November 17, 2020 11:07
To: [e-mail]
Cc: Core WG mailing list <[e-mail]>
Subject: Aligning groupcomm-proxy and mutlicast-notifications

Hello Marco and Esko,

from today's CoRE meeting I've seen that the Response-Forwarding option
has a similar structure as multicast-notifications' tp_info /
Listen-To-Multicast-Responses option.

Both share that they encode a host address (and possibly port) that
isn't typically a name but really an address, and that the underlying
protocol may not be fully understood by the client behind the proxy.

The latter is not in groupcomm-proxy as it is now, but may make sense:
All the client needs to know is that the host of the resource *is*
actually a multicast address, not how that precisely works. (It may even
take that information from somewhere else if the authority component is
a host name which the client can't resolve). What makes this a bit
tricky is that we don't have any other multicast-capable transport, but
I imagine we could have.

A related component that could play a role in the alignment is how the
address is then encoded when contacting the host directly through the
proxy. Unless the proxy is reverse (which is AFAIK not discussed at all,
and may be worth discussing on its own), if the client still wants to
use the proxy, it needs to set Proxy-Scheme: "coap" and Uri-Host:
"2001:db8::1" from the data received as srv_info =
[#6.260(h"20010db8...1")]. The information that goes into Proxy-Scheme
would currently be hardcoded; if something like multicast-notifications'
tp_info is used, that would be looked up from there. (Granted, when
follow-up requests are used, even a client that knows the tp_info is
mapped, but at least that could be an easy extension).

Anything we come up with here that works for both our use cases might
also be suitable for CRIs[1], which could then be a reusable component
in converting back and forth between (Proxy-Scheme, Uri-Host) and
something that contains binary IP addresses.

BR
c

[1]: https://tools.ietf.org/html/draft-ietf-core-href-03

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom