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

Achim Kraus <achimkraus@gmx.net> Tue, 24 March 2020 12:01 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFCD3A0928 for <core@ietfa.amsl.com>; Tue, 24 Mar 2020 05:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuxXmaPE23h7 for <core@ietfa.amsl.com>; Tue, 24 Mar 2020 05:01:45 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000363A090D for <core@ietf.org>; Tue, 24 Mar 2020 05:01:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585051299; bh=5a7hXbng4YTb4Jv26BMR9/ue0zCHfLvLYnEthyPsCSo=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=OCRCk+NQo/dOUgK6wOlgnCMtUqq8IDrPZQYLUp7Xzh6DZesDgShJe5zoueTlpIxMR mju2h5TE17pgjEqbxdqUuhiqvZdWcLKSVcPfJifegHYQPU+JiiNz1yAoId/LtVB6Fr 1spU6IzywmBynEQJRS5xrqQLR9Wy4+dd78ym7Nb8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([94.217.138.93]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MCbEp-1j89Wi1sHr-009fUR; Tue, 24 Mar 2020 13:01:39 +0100
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, "core@ietf.org" <core@ietf.org>
References: <1492100a-361b-d2ca-e1a1-f8086dfa858f@gmx.net> <AM5P190MB0275B59658F7D1C48CC5D7D6FDF10@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <16abaa01-07f2-d9eb-4ab5-e8fbedf31c38@gmx.net>
Date: Tue, 24 Mar 2020 13:01:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <AM5P190MB0275B59658F7D1C48CC5D7D6FDF10@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:AiX3we8Zqiy2rdHWKnUhJ1trPw1Wh6YWubAmmPOGRD30k5MJVIr VFp9HIYQZpqSiBK9SEzAo/EDA8UnBnbD+tAQLDe7t55kjNiEO63yruaOhykewOd6BLBtLqi aiuHWXmkNsDy+GLh89yPPP9Q+Od3YNg+WoiV0lEIUdeg7ctLsa1zkXi96YCDTG8ImjagK2p 6ulF4KsQVcT13Q5gg3N+Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:+0k9FIvl/XM=:nrxJW+qr5hRR5jid1VnBuD CN5RVkwXQECIVmD0Uet0iKXoUgPkmXvg3ydDzwTPWXunt14tLnnf4ortqtb6MHZVh/YmJW40G YxzLYeTxdu5jnRdFH+uw70zErUldC8LInQUQlrBrEIdAuUnBudqFRysJCkGWIeIwJbGdNk1RY l2oDd3BISWZ9LjdoFEhGu3llacUWfpvpvw5f7CU8UuF2ZCXElsu7MLgCmlBv1sSwVH7NYYaq0 id+QTRo7mm18x28Nd/KEYnEYTTTq7UbZqAnU+GARQotKIItN2O/6AMUuo2gA5diZgKsZ6zdV5 tRgYTM/UOhDMVUZA+ufwRuOVhoKk76M4VsME/zfEXzEfasKDxEY/JmhAIbnWHfK0F9TfZbgA2 Uj6Iqq3loSaRwgk+tRxiyzKV1f7XfQUO2l+RUlhQOGkUHr0rM0wGwXLvRzO7+TtaS2Tu135MQ gZN1nqu50duiFIjBr2uq+EcE9sfxZAnExSWaDIvTJWL0QieH6AH0Lif3bbHiOzw7Qsae4BsSh wpFIU8yIhoHRknbpaabt1LPX01a3q9PwoIHZgmdVdkyc1s6mcPSfiHP4DqIX93sivV6a5ae42 uHP7k6aFJHO7HBDQHQe3FyeCLu+mw1bg3noGq3x5s+HQZ9liMxw2ecbJz/l2a7lx+BSEulbWA b+aiqEOnBPn75mKxhp0B2IXgWA4g3AhUVjJ3moDBj8mKRbHrp0oPBT6lTVTAMnGZ47MK8s4dr VfWU61KZfPiL1v+11KcOlq791I2bVB8R6iJyAMWsDI5Rhs6khTuLWS2xECnRv39gxX78djBYd T1RPYUj8N0aO92pZRxPinrd/tO1np2NXMdCZDEIwoVbYYkEENk1Zb9Qe3O1Z1PQBTlI3Ph56O qf6pGYYw2O8fm8QKVo2te4Ifuie+/DmZnfhRqsQE9E7qRb/q63MhjyJrFcJePxXNWClkMZghL 4qZWdM3+TkL2Wn/MqS7RzSs1/NYtO3ZUMblWqP7IVFPCupAugLXYJ9/0eafuECAN8VzqUTBg5 glmU2POzZvp7HOTFTgnfw+1Sk6aLUNe/F0qwndssIr3S9E+MK79WJRaO+RldHN/U1gXbN0xvo qYsD/TlhaLkbPLrIKKvyQvrytEhXFP0kqkLA0I6eU5yKm9D9dv1Jmg4QWiebo7r+mGUVlQCZo keSFA1vwDjuED2aZ1EQcPnWQNbAPBFAnNw2F3l9ROSY9MBXTC9ellA7YyK7MC1ZEMHN6IzPZC rzd+5K1L48RAhzHDb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tFe24l4PELejhrAKktPdRgxnrc8>
Subject: Re: [core] WGA of draft-dijk-core-groupcomm-bis-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 12:01:47 -0000

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

Am 24.03.20 um 11:37 schrieb Esko Dijk:
> 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 <core-bounces@ietf.org> On Behalf Of Achim Kraus
> Sent: Friday, March 20, 2020 09:37
> To: core@ietf.org
> Subject: Re: [core] WGA of draft-dijk-core-groupcomm-bis-03
>
> 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
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>