Subject: Re: [core] WGA of draft-dijk-core-groupcomm-bis-03

From: Achim Kraus <[email-masked]>
Date: Fri, 20 Mar 2020 09:36:51 +0100

Hello list,

the draft "draft-dijk-core-groupcomm-bis-03" mention in
2.1 Group Definition

"An endpoint may be a member of multiple CoAP groups by subscribing to
multiple IP multicast groups."

At least for java, we (Eclipse Californium) didn't find a way for the
server-side, to determine, for which multicast group the message was
received. We even didn't find a way to distinguish on the server-side,
if the message was received through a multicast group or uni-cast
address. An approach, which uses "many ports", and so different
endpoints, has it's downsides (the document mentions them).
To overcome that for a "private deployment", I started to use the
"Uri-Host" option to send he destination "multicast group" as convention.

Maybe, if group communication gets more elaborated, the core wg consider
to spend a specific (new) option "multicast-group" in order to make it
easier/possible, to implement a proper server-side.

best regards
Achim Kraus

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Mar 2020 10:48:56 +0100

On 2020-03-20, at 09:36, Achim Kraus <[email-masked]> wrote:
> received.

A workaround for less capable platforms has always been to open multiple sockets, one for each address.  Would that work here, too?

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Fri, 20 Mar 2020 19:59:46 +0100

Hi Carsten,

let me first also thank you very much for your work over the past 10
years (and now even 10 more days ;-) )!

 > A workaround for less capable platforms has always been to open
multiple sockets, one for each address.  Would that work here, too?

To distinguish between multicast groups, yes (with some of the downsides
mentioned in the draft).

To distinguish between multicast and uni-cast, I can't see, that this is
working.

One of my impression working with java-multicast is, that it depends a
little more on the OS implementations. Therefore an option seems for me
to be the easier approach. Anyway, lets see, if other implementations
have also their trouble implementing it.

best regards
Achim

---

From: Esko Dijk <[email-masked]>
Date: Tue, 24 Mar 2020 10:37:52 +0000

Hello Achim,

Thanks for your email and raising this point. The groupcomm-bis-03 draft now defines more explicitly the concepts of CoAP group, application group and security group.
If the CoAP group cannot be determined by the server, that should not be a problem when considering these 3 group concepts. By the fact that the message is received, the server knows that the message is targeting at least one CoAP group that it has joined.

How the server handles the request is not determined by the CoAP group but normally by the URI path (indicating the resource) and the URI query options (if any).
In groupcomm-bis we indicate that the application group may be optionally encoded in the URI path (e.g. /lights/g4/brightness to control brightness of all application-group g4 lights within a single luminaire device) or in the URI query (e.g. /lights/brightness?grp=g4) .

In addition, also security group needs to be considered. The server will need to check that the right security group is present in the request before processing the request for a specific resource or resource-plus-application-group indicator.
(For example, only an authenticated client that is member of group 'g4' can make a request to the /lights/g4/...  set of resources. CoAP group is then not so relevant anymore.)

You mention the "Uri-Host" option used to select a destination group, that is certainly possible - it influences the choice of application group according to the definitions in groupcomm-bis. (Maybe we should explain this in the draft also. Thomas had also a Uri-Host comment!)
So by looking at the value of "Uri-Host", a server can decide on different processing of the request. (For example, a request to resource /lights/brightness could operate differently depending on the contents of Uri-Host e.g. "g4" and also have different security requirements depending on that value. So each virtual server in the same endpoint serves resources for a different application group.).
The reason that "Uri-Host" does not impact selection of CoAP group is because CoAP group is defined at endpoint level only; and multiple virtual servers are within the same endpoint.

All in all, the server's processing of the request depends on URI path / URI query in a particular security context - and the CoAP group should not play a role in that anymore as this is more about getting the message to the right set of nodes.  If it does play a role then what you are really selecting is different application groups (that might be named after CoAP groups - but still they are application groups) and for that we have various tools at the moment: URI path, URI query and URI host option. Adding another tool to this like a "group selection option" would be possible though I feel URI path is the most logical place to encode application group!

Best regards
Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Friday, March 20, 2020 09:37
To: [email-masked]
Subject: Re: [core] WGA of draft-dijk-core-groupcomm-bis-03

Hello list,

best regards
Achim Kraus

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Achim Kraus <[email-masked]>
Date: Tue, 24 Mar 2020 13:01:38 +0100

Hello Esko,

thanks for your answer!

 > How the server handles the request is not determined by the CoAP
group but normally by the URI path (indicating the resource) and the URI
query options (if any).

That maybe acceptable for different multicast groups, but 2.3.4 may get
harder.

(from my initial mail)
 >> We even didn't find a way to distinguish on the server-side, if the
message was received through a multicast group or uni-cast address.

I still don't see, that it's possible to distinguish on the server-side,
if the message was received through a multicast group or uni-cast
address. But for 2.3.4 that seems to be important.

2.3.4.  Congestion Control

"A server may choose not to respond to an IP multicast request if
there is nothing useful to respond to, e.g., error or empty
response (see Section 8.2 of [RFC7252])."

Not possible without distinguish, if the message was received through a
multicast group or uni-cast address.

"A server should limit the support for IP multicast requests to
specific resources where multicast operation is required
(Section 11.3 of [RFC7252])."

Not possible without distinguish, if the message was received through a
multicast group or uni-cast address. If the support multicast operation
on a resource should be depend on the used "multicast group", then this
will be alos not possible.

"A server does not respond immediately to an IP multicast request
and should first wait for a time that is randomly picked within a
predetermined time interval called the Leisure (Section 8.2 of
[RFC7252])."

Not possible without distinguish, if the message was received through a
multicast group or uni-cast address.

"A server in a constrained network should only support group
communication GET for resources that are small."

Not possible without distinguish, if the message was received through a
multicast group or uni-cast address.

 > You mention the "Uri-Host" option used to select a destination group,
that is certainly possible - it influences the choice of application
group according to the definitions in groupcomm-bis. (Maybe we should
explain this in the draft also. Thomas had also a Uri-Host comment!)
 > So by looking at the value of "Uri-Host", a server can decide on
different processing of the request. (For example, a request to resource
/lights/brightness could operate differently depending on the contents
of Uri-Host e.g. "g4" and also have different security requirements
depending on that value. So each virtual server in the same endpoint
serves resources for a different application group.).

With the current definition in RFC 7252, 6.4. "Decomposing URIs into
Options", a "IP-literal or IPv4address" multicast address is not
included as URI-Host option. If that get's adapted to be inlcuded for
multicast, then a server can distinguish between unicast (n.a. or
unicast) and multicast (multicast) and even more process selective on
the multicast groups (e.g. for improved congestion control).
Though I'm not sure, if that may overload the usage of URI-host too
much, I proposed a different option. But, if the URI-host usage gets
adapted, that may also help to solve the implementation issues.

best regards
Achim Kraus