Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Jim Schaad <ietf@augustcellars.com> Wed, 01 April 2020 21:35 UTC

Return-Path: <ietf@augustcellars.com>
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 A835C3A0BD9 for <core@ietfa.amsl.com>; Wed, 1 Apr 2020 14:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 twN6msxVWRMQ for <core@ietfa.amsl.com>; Wed, 1 Apr 2020 14:35:23 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26ED83A0BD7 for <core@ietf.org>; Wed, 1 Apr 2020 14:35:22 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Apr 2020 14:35:10 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Esko Dijk' <esko.dijk@iotconsultancy.nl>, 'Klaus Hartke' <hartke@projectcool.de>
CC: 'Achim Kraus' <achimkraus@gmx.net>, <core@ietf.org>
References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <AM5P190MB027536259A44102F7AB9E058FDC80@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAAzbHvbeEyws+wVchovoVTK=WutWoHCNcfv8LrpxmshLxJ_w+Q@mail.gmail.com> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <AM5P190MB0275218BA7C801E50C8353F0FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <AM5P190MB0275218BA7C801E50C8353F0FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
Date: Wed, 1 Apr 2020 14:35:09 -0700
Message-ID: <01bc01d6086d$6ca1d150$45e573f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIXVeiVC1e4HIxpxUNqDgp/ppWwxwLeBdy3AlRjDEICXv5oEAIsRnhBAgGYZE4CNTatAadyiDoQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/BMamYZY2cEkHvCpb4LnaO1lz6XQ>
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
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: Wed, 01 Apr 2020 21:35:26 -0000


-----Original Message-----
From: Esko Dijk <esko.dijk@iotconsultancy.nl> 
Sent: Wednesday, April 1, 2020 1:19 AM
To: Jim Schaad <ietf@augustcellars.com>om>; 'Klaus Hartke' <hartke@projectcool.de>
Cc: 'Achim Kraus' <achimkraus@gmx.net>et>; core@ietf.org
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Thanks Klaus & Jim, 

it is clear to me now how you view the endpoint concept for multicast messages. Because (to me) this is not fully compatible with the definitions of "endpoint" and messaging model in RFC 7252 that I quoted, it would be good to clarify this aspect more in draft-ietf-core-groupcomm-bis i.e. refine the RFC 7252 endpoint definitions for the multicast case and clarify the multicast messaging model.  I guess the rationale for the "mailing list" type behavior is that the receiving node anyhow changes the endpoint (by changing multicast IP address to a unicast IP address) so it could change the port number as well, the responding endpoint will anyhow be different. (To me that was unexpected and feels not entirely right  - port number should not need to change, but I can live with it.)

I'm assuming by now there are no different opinions from the list on this question anymore, so I'll proceed with some text for draft-ietf-core-groupcomm-bis. Maybe a "SHOULD" level requirement on keeping the UDP port number the same? And indicate if there are any good reasons to change port number the server can do just that.

[JLS] I do not believe that there is any reason to have a "SHOULD" requirement on keeping the port number the same.  If you want to say on the allocated multicast address that has been registered with IANA, then you are going to end up with different applications living on different ports.  There are trade offs for using different ports than different addresses.  The biggest being the idea of a well known address - using the default port and default multicast address, vs making sure that you minimize the traffic that a server needs to process by using different addresses rather than different ports.  

	Jim


Esko

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com> 
Sent: Tuesday, March 31, 2020 18:52
To: 'Klaus Hartke' <hartke@projectcool.de>de>; Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: 'Achim Kraus' <achimkraus@gmx.net>et>; core@ietf.org
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top



-----Original Message-----
From: Klaus Hartke <hartke@projectcool.de> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Achim Kraus <achimkraus@gmx.net>et>; Jim Schaad <ietf@augustcellars.com>om>; core@ietf.org
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko Dijk wrote:
> However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

Yes. In the simple CoAP-over-UDP unicast NoSec case, if a request message is sent from an endpoint 192.168.0.1:54321 ("client") to an endpoint 192.168.0.100:5683 ("server"), the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

The response message cannot be sent from any other endpoint, because then the client couldn't match the incoming message to its pending request (it would appear to come from a different server). The response message also cannot be sent to any other endpoint, because then the client wouldn't get the message (it would be sent to a different client).

I view multicast messages basically like e-mail mailing lists. E.g.
(IMO): A request message is sent from the endpoint 192.168.0.1:54321 to the special endpoint 224.0.1.187:9999, the message magically shows up as incoming message at the endpoint 192.168.0.100:5683, and the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

[JLS] What he said.  And then after the first message comes in from 192.168.0.100:5683, all of the messages from that endpoint are correlated together so that you can do things like blockwise.

Klaus