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

From: Esko Dijk <[email-masked]>
Date: Wed, 1 Apr 2020 08:18:58 +0000

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.

Esko

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Tuesday, March 31, 2020 18:52
To: 'Klaus Hartke' <[email-masked]>; Esko Dijk <[email-masked]>
Cc: 'Achim Kraus' <[email-masked]>; [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <[email-masked]>
Cc: Achim Kraus <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
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

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 1 Apr 2020 09:45:33 +0100

Hi Esko, all,

On Wed, Apr 1, 2020 at 9:19 AM Esko Dijk <[email-masked]> wrote:
> (To me that was unexpected and feels not entirely right  - port number should not need to change, but I can live with it.)

I have the same trouble as you understanding the port mapping part.
Where is that supposed to happen (kernel, CoAP stack, application)?
And why is it needed?

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

I don't have an opinion yet, but I'd need some clarification about the
above before feeling comfortable with the direction...

Cheers, thank you!

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 1 Apr 2020 12:55:45 +0200

> above before feeling comfortable with the direction...

I guess there is some room for debate on what a CoAP endpoint with a
multicast IP address precisely means... RFC 7252 defines 224.0.1.187
as the "All CoAP Nodes" address. So I see at least two possible
interpretations for the endpoint 224.0.1.187:9999:

1. All CoAP nodes that are listening on port 9999 on their unicast IP address.

2. All CoAP nodes that are "subscribed" to mailing list 9999.

Both seem to have advantages and disadvantages. Maybe there are even
more interpretations?

> Where is that supposed to happen (kernel, CoAP stack, application)?

I always imagined multicast CoAP to work roughly like this:

+---------------+                +-----------------+
|               |    request    _|_                |
|               |        .---> /   \   224.0.1.187 |
|              _|_      /      \___/ --.   :9999   |
| 192.168.0.1 /   \ ---´         |      \          |
|   :54321    \___/ <---.       _|_     /  rewrite |
|               |        \     /   \ <-´           |
|               |         `--- \___/ 192.168.0.100 |
|               |    response    |         :5683   |
+---------------+                +-----------------+
      Client                           Server

So, a server is listening for request messages on both a unicast IP
address/port and a multicast IP address/port. If a request message
arrives on the multicast IP address/port, it "rewrites" the UDP
destination to its unicast IP address/port and then processes the
message as if it had received it on its unicast IP address/port.

The "rewrite" is at least needed for the IP address, because the
server cannot send its response from the multicast IP address.

Klaus

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 1 Apr 2020 16:41:18 +0100

Hey Klaus,

> 1. All CoAP nodes that are listening on port 9999 on their unicast IP address.

This interpretation doesn't look right to me.

> 2. All CoAP nodes that are "subscribed" to mailing list 9999.

This is how I interpret it.

> I always imagined multicast CoAP to work roughly like this:

Not sure why you would also want to rewrite the transport endpoint?

cheers, thanks!

---

From: Achim Kraus <[email-masked]>
Date: Wed, 1 Apr 2020 22:28:01 +0200

Hi,

Nice diagram.

> Not sure why you would also want to rewrite the transport endpoint?

I tried to follow the discussion.
The idea to change the port as well enables java (and I guess some more)
to differentiate between multicast and unicast requests. Jim also
mentioned, that it enables the use of multiple servers on the same host.
I have not enough experience with multicast in different environments to
see, if that may cause more trouble (e.g. firewall etc.). I would guess,
that some  implementations will just offer that variant, at least as
configurable option (I would try do so for Californium).
So my favorite for now is just implement it and see, what the user's
feedback will be.

If that idea gets declined (may be by negative feedback of users), I
still think, that there is a demand for other means to distinguish
between multicast and unicast requests. Maybe, either the usage of the
uri-host option or a new option will help.

This maybe considered as "too pragmatically", but on the other side I
also don't see the "great benefit" in insist not to change the port.

best regards
Achim

---

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Apr 2020 14:35:09 -0700

-----Original Message-----
From: Esko Dijk <[email-masked]> 
Sent: Wednesday, April 1, 2020 1:19 AM
To: Jim Schaad <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: 'Achim Kraus' <[email-masked]>; [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Thanks Klaus & Jim, 

[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 <[email-masked]> 
Sent: Tuesday, March 31, 2020 18:52
To: 'Klaus Hartke' <[email-masked]>; Esko Dijk <[email-masked]>
Cc: 'Achim Kraus' <[email-masked]>; [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <[email-masked]>
Cc: Achim Kraus <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Klaus

---

From: Esko Dijk <[email-masked]>
Date: Thu, 2 Apr 2020 08:14:13 +0000

Hello Jim,

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

No I was not referring specifically to IANA allocated multicast addresses - I meant for any multicast addresses. Because the "usual" approach of unicast is to respond from the same endpoint (address + UDP port) that was receiving the request, the rule should be for multicast the same where possible. Now for the address that's obviously not possible but the UDP port value can at least remain the same. So the idea is to recommend to keep that the same *unless* there's a good reason to change it on the server side. 

Some reasons to do so were mentioned by you and discussed in this thread, e.g. as a way to differentiate a unicast vs a multicast request. Or to "internally delegate" in the server a request to a server on another endpoint.
If a "SHOULD" is not right then perhaps a "recommended" without capitals is right. A "MAY" is not needed here because per RFC 7252 the client already has a lenient matching algorithm - using only the Token value. So we don't need an additional "server MAY change port number" as a means to force the client to not match responses based on the source UDP port number, because RFC 7252 already tells that.

Esko

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Wednesday, April 1, 2020 23:35
To: Esko Dijk <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: 'Achim Kraus' <[email-masked]>; [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

-----Original Message-----
From: Esko Dijk <[email-masked]> 
Sent: Wednesday, April 1, 2020 1:19 AM
To: Jim Schaad <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: 'Achim Kraus' <[email-masked]>; [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Thanks Klaus & Jim, 

	Jim

Esko

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Tuesday, March 31, 2020 18:52
To: 'Klaus Hartke' <[email-masked]>; Esko Dijk <[email-masked]>
Cc: 'Achim Kraus' <[email-masked]>; [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <[email-masked]>
Cc: Achim Kraus <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Klaus

---

From: Esko Dijk <[email-masked]>
Date: Thu, 2 Apr 2020 08:22:51 +0000

Hello Achim,

(see also my response to Jim)
Using the UDP port number to detect a multicast request vs a unicast request sounds like a good use case. Just curious - I assume the security aspect requirements of RFC 7252 are taken care of in this use case?

That is, a proper client sends its multicast requests always to port :9999 and the server treats these as multicast requests (e.g. only allow the request for specific resources).
A malicious client may sends its multicast request to port :5683 to bypass the above checks. I assume the server doesn't respond to this request, because the multicast address is not bound to port 5683 but to say 9999 only.
If the CoAP server at port 5683 cannot distinguish between unicast/multicast that would be a bad situation and the security requirements of RFC 7252 are not met.

Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Wednesday, April 1, 2020 22:28
To: Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi,

Nice diagram.

best regards
Achim

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

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 2 Apr 2020 11:19:37 +0100

On Wed, Apr 1, 2020 at 9:19 AM Esko Dijk <[email-masked]> wrote:
> 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.

+1

Ideally, this new "multicast CoAP endpoint" definition should also
include an explanation why source address and port of the unicast
response are irrelevant to the successful processing at the client.

If we can express that clearly I don't think we need "SHOULD keep the
same UDP port": an implementation is left with its own local choice.

As a bonus we could also have implementation (in which scenario port
translation is a useful technique) as well as operational considerations
(Achim's wireshark filtering argument).

My two cents,
cheers!

---

From: Jim Schaad <[email-masked]>
Date: Thu, 2 Apr 2020 09:01:30 -0700

Esko,

That idea strikes me as a very bad idea.   If you build your code on this basis you will fall over the first time you come across a multicast channel which uses the same port as the unicast server.   The IP address is different for a multicast vs a unicast message received at the server.  This needs to be the distinction as well as the fact that some resources may only want to be on a single multicast address even if the server is listening on multiple unicast addresses.

Jim

-----Original Message-----
From: core <[email-masked]> On Behalf Of Esko Dijk
Sent: Thursday, April 2, 2020 1:23 AM
To: Achim Kraus <[email-masked]>; Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hello Achim,

Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Wednesday, April 1, 2020 22:28
To: Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi,

Nice diagram.

I tried to follow the discussion.
The idea to change the port as well enables java (and I guess some more) to differentiate between multicast and unicast requests. Jim also mentioned, that it enables the use of multiple servers on the same host.
I have not enough experience with multicast in different environments to see, if that may cause more trouble (e.g. firewall etc.). I would guess, that some  implementations will just offer that variant, at least as configurable option (I would try do so for Californium).
So my favorite for now is just implement it and see, what the user's feedback will be.

If that idea gets declined (may be by negative feedback of users), I still think, that there is a demand for other means to distinguish between multicast and unicast requests. Maybe, either the usage of the uri-host option or a new option will help.

This maybe considered as "too pragmatically", but on the other side I also don't see the "great benefit" in insist not to change the port.

best regards
Achim

---

From: Esko Dijk <[email-masked]>
Date: Fri, 3 Apr 2020 12:38:18 +0000

Hello Jim,

Could you clarify your point further? 
- what is a bad idea - having a dedicated port with dedicated for handling multicast requests?  Or the subsequent "internal routing" of the request to the unicast server at a different port? Or both?
- what is a "multicast channel" , do you mean an endpoint bound to a multicast address ?

> some resources may only want to be on a single multicast address even if the server is listening on multiple unicast addresses

Sure, you can also have a dedicated server on say port :9999 that listens to multicast destination addresses only, because it is bound only to a multicast address not a unicast address. This dedicated server can then handle resources that only are to be accessed via multicast.
But in this case, there's no "internal routing" needed to another server inside the node because the resource is only hosted at say port :9999.

> The IP address is different for a multicast vs a unicast message received at the server.  This needs to be the distinction

But the case the Achim indicated is that the server may not be able to detect whether a request came in via unicast of multicast. So this cannot be the distinction, e.g. in the following case:
1) CoAP server at port 5683 is bound to unicast address U
2) at same node, same CoAP server at port 5683 is bound to multicast address M

Now in this case if a request comes in via multicast group M destined  to port 5683, the server handling this cannot tell whether it was unicast or multicast. And if a unicast request comes in to destination address U and port 5683, the server cannot tell also whether that was unicast or multicast.

By setting it up like this instead that problem is avoided:
1) CoAP server at port 5683 is bound to unicast address U
2) at same node, same CoAP server at port 9999 is bound to multicast address M
Then the server at port 5683 treats everything as unicast. (Because it is not bound to a multicast address, it won't receive any multicast requests directly.)
And the server at port 9999 treats everything as multicast. (And this endpoint 9999 handles most requests by internally redirecting to server :5683, but only for those resources where multicast is allowed. Some request for multicast-only resources it can handle itself directly.)

So the above "workaround" seems handy for cases where a server at one specific UDP cannot itself determine the endpoint the request came in from (could be either multicast like M or unicast like U).

@Achim maybe you could comment if I've understood your use case properly.  To me the above seems more secure than trusting that a client will include a "This is multicast" CoAP Option in an honest way, which could easily be misused.

thanks
Esko

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Thursday, April 2, 2020 18:02
To: Esko Dijk <[email-masked]>; 'Achim Kraus' <[email-masked]>; 'Thomas Fossati' <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko,

Jim

-----Original Message-----
From: core <[email-masked]> On Behalf Of Esko Dijk
Sent: Thursday, April 2, 2020 1:23 AM
To: Achim Kraus <[email-masked]>; Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hello Achim,

Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Wednesday, April 1, 2020 22:28
To: Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi,

Nice diagram.

best regards
Achim

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Apr 2020 10:54:07 -0700

-----Original Message-----
From: Esko Dijk <[email-masked]> 
Sent: Friday, April 3, 2020 5:38 AM
To: Jim Schaad <[email-masked]>; 'Achim Kraus' <[email-masked]>; 'Thomas Fossati' <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hello Jim,

Could you clarify your point further? 
- what is a bad idea - having a dedicated port with dedicated for handling multicast requests?  Or the subsequent "internal routing" of the request to the unicast server at a different port? Or both?
[JLS] I think it is a bad idea to use the port number as a means of distinguishing multicast and unicast message.    If you do something like this completely internal to your own code, then it is an implementation detail but would not map to any type of text for an IETF document.

- what is a "multicast channel" , do you mean an endpoint bound to a multicast address ?
[JLS] I use the word channel because it maps from my code base in many ways.  A "multicast channel" would map to an endpoint bound to a <multicast address, port> pair.  An analogy for those of us who are really old would be to consider UHF and VHF on your TV to be different multicast addresses, but you still need to choose the channel number (port number) in order to get a flow of information that is usable. The analogy of course breaks down because you cannot send information back to the TV stations.

> some resources may only want to be on a single multicast address even 
> if the server is listening on multiple unicast addresses

Sure, you can also have a dedicated server on say port :9999 that listens to multicast destination addresses only, because it is bound only to a multicast address not a unicast address. This dedicated server can then handle resources that only are to be accessed via multicast.
But in this case, there's no "internal routing" needed to another server inside the node because the resource is only hosted at say port :9999.
[JLS] You can have a dedicated server on say <address, port=9999> that lists for multicast traffic.  You always have the address and port as a pair.  

> The IP address is different for a multicast vs a unicast message 
> received at the server.  This needs to be the distinction

But the case the Achim indicated is that the server may not be able to detect whether a request came in via unicast of multicast. So this cannot be the distinction, e.g. in the following case:
1) CoAP server at port 5683 is bound to unicast address U
2) at same node, same CoAP server at port 5683 is bound to multicast address M
[JLS]  If this is really true, and I am not sure that I believe that to be the case, then the JAVA library is completely broken and needs to get fixed.    The fast look that I had at the JAVA library looks like you need to create a distinct socket for every <address, port> pair that you are dealing with.  I think that should give you all of the info that you need, but like I said, I have not done the JAVA programming itself.

Now in this case if a request comes in via multicast group M destined  to port 5683, the server handling this cannot tell whether it was unicast or multicast. And if a unicast request comes in to destination address U and port 5683, the server cannot tell also whether that was unicast or multicast.
[JLS] What is the address that is associated with the port number?  You cannot have a bare port number you also must have an IP address.  The IP address is how you distinguish unicast/multicast.

[JLS]  Jim

By setting it up like this instead that problem is avoided:
1) CoAP server at port 5683 is bound to unicast address U
2) at same node, same CoAP server at port 9999 is bound to multicast address M Then the server at port 5683 treats everything as unicast. (Because it is not bound to a multicast address, it won't receive any multicast requests directly.) And the server at port 9999 treats everything as multicast. (And this endpoint 9999 handles most requests by internally redirecting to server :5683, but only for those resources where multicast is allowed. Some request for multicast-only resources it can handle itself directly.)

thanks
Esko

-----Original Message-----
From: Jim Schaad <[email-masked]>
Sent: Thursday, April 2, 2020 18:02
To: Esko Dijk <[email-masked]>; 'Achim Kraus' <[email-masked]>; 'Thomas Fossati' <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: [email-masked]
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko,

Jim

-----Original Message-----
From: core <[email-masked]> On Behalf Of Esko Dijk
Sent: Thursday, April 2, 2020 1:23 AM
To: Achim Kraus <[email-masked]>; Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hello Achim,

Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Wednesday, April 1, 2020 22:28
To: Thomas Fossati <[email-masked]>; Klaus Hartke <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi,

Nice diagram.

best regards
Achim

---

From: Achim Kraus <[email-masked]>
Date: Mon, 6 Apr 2020 15:42:19 +0200

Hi Esko,
Hi Jim,

as I promised to Jim, I spent some time over the weekend to investigate
more about the java-multicast features. A prepared a Californium PR with
my results.

Generall I still feel, that it is much easier, to use a differnt ports
for multicast and unicast, than to try to use the same port for
multicast and unicast simultaneously.
Over the weekend I failed frequently, sometimes it ended even in
situations, where the multicast request reaches all endpoints (multicast
and unicast) and the deduplication then got activated.  It's not even
easy to see, if the server really differentiate between unicast und
multicast reliable. On my experiments it first shows as "random", if the
response indicates a unicast or multicast request. Then I found, that
the request was delivered to all endpoints and just the first response
was also used for the other requests. When I introduced a warning in the
deduplication, I saw much more frequently, that the setup is still
broken or got broken again. Therefore I would consider, that using the
same port requires intensive test or much more guidance how to setup the
multicast endpoint in order to work reliable.
So I'm everything else than sure, that the current setup in Califonium
will work reliable for different OS and java versions. We will see.

Somehow my personal feeling is, that other protocols don't distinguish
the processing of received records based on receiving them  via unicast
or multicast. If so, that pattern using a different ports for multicast
and unicast in order to reliable distinguish between multicast and
unicast, would be easier to support.

best regards
Achim

---

From: Achim Kraus <[email-masked]>
Date: Tue, 7 Apr 2020 10:12:23 +0200

Hello Jim,

 > [JLS] I think it is a bad idea to use the port number as a means of
distinguishing multicast and unicast message.    If you do something
like this completely internal to your own code, then it is an
implementation detail but would not map to any type of text for an IETF
document.

Do you have an example, where a IETF specification uses multicast and
unicast and differs in processing on that? Otherwise the point maybe,
that other protocols, which also support multicast, process any request
in the same way, regardless if it's received via the unicast or
multicast address.

 > [JLS]  If this is really true, and I am not sure that I believe that
to be the case, then the JAVA library is completely broken and needs to
get fixed.    The fast look that I had at the JAVA library looks like
you need to create a distinct socket for every <address, port> pair that
you are dealing with.  I think that should give you all of the info that
you need, but like I said, I have not done the JAVA programming itself.

At least, it is easier to mix it up, than to do it proper.
And "wrong" maybe not too obvious, because it requires precise
mechanisms to detect that. And it may vary from OS to OS.
For linux the multicast socket seems to require to be bound to the
specific multicast address, for windows that doesn's work and seems to
be not required. So, lets see, if only "my limited java multicast
knowledge" is the gap, or other implementations will also struggle :-).

best regards
Achim

---

From: Jim Schaad <[email-masked]>
Date: Fri, 10 Apr 2020 13:42:24 -0700

I have spent the last week trying to solve the same problem using Java that I have done for C#.  In C# there is a function on a socket called ReceivedMessageFrom that provides the local address on which the message was received.  This allows me to correctly propagate that information up the stack to the client code so that it can make the distinctions needed.

I failed.  It seems that Java decided not to provide the level of support needed to do this.

I have some worries about the solution of saying that you are going to use a port number to distinguish between the two cases.  First any multicast applications out there might already be using the current port number.  Second, in order to do this you are going to open a unicast server on that same port number.  That is you are going to end up needing to service unicast on both port numbers as well as dealing with the redirection of port numbers in your internal code.  Admittedly, if you always do the port number redirection you will get clients that send messages and cannot deal with the received messages as the address 4-tuple will not line up.  A third problem is that you may need to have a different port number for every multicast address.  This is because you are not going to be able to tell which multicast address a request came in if they are on the same ports.

This is not a problem for my code base, it would not be a problem for a device that is running directly on top of a low level socket.  I don't know what to say.

jim

-----Original Message-----
From: Achim Kraus <[email-masked]> 
Sent: Monday, April 6, 2020 6:42 AM
To: Jim Schaad <[email-masked]>; 'Esko Dijk' <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi Esko,
Hi Jim,

as I promised to Jim, I spent some time over the weekend to investigate more about the java-multicast features. A prepared a Californium PR with my results.

Generall I still feel, that it is much easier, to use a differnt ports for multicast and unicast, than to try to use the same port for multicast and unicast simultaneously.
Over the weekend I failed frequently, sometimes it ended even in situations, where the multicast request reaches all endpoints (multicast and unicast) and the deduplication then got activated.  It's not even easy to see, if the server really differentiate between unicast und multicast reliable. On my experiments it first shows as "random", if the response indicates a unicast or multicast request. Then I found, that the request was delivered to all endpoints and just the first response was also used for the other requests. When I introduced a warning in the deduplication, I saw much more frequently, that the setup is still broken or got broken again. Therefore I would consider, that using the same port requires intensive test or much more guidance how to setup the multicast endpoint in order to work reliable.
So I'm everything else than sure, that the current setup in Califonium will work reliable for different OS and java versions. We will see.

Somehow my personal feeling is, that other protocols don't distinguish the processing of received records based on receiving them  via unicast or multicast. If so, that pattern using a different ports for multicast and unicast in order to reliable distinguish between multicast and unicast, would be easier to support.

best regards
Achim

Am 03.04.20 um 19:54 schrieb Jim Schaad:
> To: Jim Schaad <[email-masked]>; 'Achim Kraus' 
> <[email-masked]>; 'Thomas Fossati' <[email-masked]>; 'Klaus 
> Hartke' <[email-masked]>
> Cc: [email-masked]
> 2) at same node, same CoAP server at port 9999 is bound to multicast 
> address M Then the server at port 5683 treats everything as unicast. 
> (Because it is not bound to a multicast address, it won't receive any 
> multicast requests directly.) And the server at port 9999 treats 
> everything as multicast. (And this endpoint 9999 handles most requests 
> by internally redirecting to server :5683, but only for those 
> resources where multicast is allowed. Some request for multicast-only 
> resources it can handle itself directly.)
>
> To: Esko Dijk <[email-masked]>; 'Achim Kraus' 
> <[email-masked]>; 'Thomas Fossati' <[email-masked]>; 'Klaus 
> Hartke' <[email-masked]>
> Cc: [email-masked]
> To: Achim Kraus <[email-masked]>; Thomas Fossati 
> <[email-masked]>; Klaus Hartke <[email-masked]>
> Cc: [email-masked]

---

From: Achim Kraus <[email-masked]>
Date: Sat, 11 Apr 2020 07:36:44 +0200

Hi Jim,
Hi Esko,

 > This is not a problem for my code base, it would not be a problem for
a device that is running directly on top of a low level socket.  I don't
know what to say.

My biggest worry about that is, that each platform should proof
reliable, that unicast only receives unicast messages and not accidently
sometimes multicast. One recommendation maybe to add a warning in the
deduplicator, if the duplicate requests differ in unicast/multicast.

best regards
Achim