Subject: [core] Message ID in draft-ietf-core-coap-14.txt

From: Pierre DAVID <[email-masked]>
Date: Fri, 12 Apr 2013 14:10:18 +0200

Hi,

in draft-ietf-core-coap-14.txt, section 4.4 (Message Correlation), I have
a problem regarding the implementation note for Message ID generation.

It is said:

    Endpoints dealing with large numbers of transactions
    could keep multiple Message ID variables, for example per prefix
    or destination address

If I generate Message IDs per *destination address*, how do I deal with
broadcast/multicast addresses? It can generate collisions on Message IDs.

Let's take the case where I have (say on node N):
- an ID generator for unicast address A
- an ID generator for broadcast or multicast address B
The node A may thus receive the same message ID (with a low probability)
for a unicast message from N to A and for a broadcast/multicast message
from N.

In my opinion, the Message ID can not be generated by destination address
nor by prefix.

Have I missed something?

Pierre David

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Apr 2013 15:10:37 +0200

> for a unicast message from N to A and for a broadcast/multicast message

Unless the recipient is RFC 3542-challenged, it could find out whether the message was addressed to it by unicast or to the multicast group.
But, indeed, there may be RFC 3542-challenged nodes.
Another problem is any RST generated in such a situation:  
That comes from the unicast address of A and goes to N, using the message-ID set by N.  
If N has used the same message ID for A and for B, it won't be able to find out which message is being rejected.

So the best way to handle multicast is to namespace the message-IDs: 
reserve a little part of the message-ID space for the multicast messages you are going to send, and do global allocation out of them.

Do you think this subject should receive more attention in the coap spec?
As in "As a multicast message may reach endpoints who may not be able to recognize the message as a multicast message, care must be taken to avoid overlap between message-IDs used for unicast and multicast messages."?
Or should we move more of the implementation notes to the LWIG document that contains a more detailed discussion of message-ID handling?

Grüße, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 12 Apr 2013 15:20:42 +0200

Dear Pierre David,
the problem you are pointing out is quite interesting in my opinion.

In the current draft has been made the (typical?) assumption that each
destination address, i.e., (IP, port) pair, corresponds to a different
endpoint. The case you propose is just one of those where this
assumption does not hold anymore. Some other cases very similar that I
am thinking about are:

1. multihomed hosts, i.e., hosts with multiple IP addresses all
pointing to the same machine

2. CoAP servers listening on multiple ports

Some time ago there was also discussion about using a 16-bit internal
clock value for generating MIDs, as long as the requirement in CoAP
spec is met:
   The same Message ID MUST NOT be re-used (in communicating with the
   same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).

If this is the case it has collision probability equal to 1, as long
as the communications we are talking about happen during the
granularity period of the internal clock (e.g. depending on hardware
and internal clock they typically range between 1 second and 1
millisecond, as far as I know).

To avoid reusing the same MID with the *same endpoint* within
EXCHANGE_LIFETIME, we probably can't rely on the (IP, port) address
pair as endpoint identifier.

Best,
Angelo

2013/4/12 Pierre DAVID <[email-masked]>:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Pierre DAVID <[email-masked]>
Date: Fri, 12 Apr 2013 16:13:27 +0200

> Or should we move more of the implementation notes to the LWIG document that contains a more detailed discussion of message-ID handling?

IMHO, distinguish MIDs for messages addressed via unicast or
broadcast/multicast is a too heavy burden in for a really constrained
node. If I had to vote, I would remove this implementation note from
the current draft.

Pierre

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 12 Apr 2013 16:07:07 +0000

Hi Carsten,

> Unless the recipient is RFC 3542-challenged, it could find out whether the message was addressed to it by unicast or to the multicast group.
I thought that for deduplication purposes this information (whether message was unicast or multicast) is not used?
Section 4.5: " (as indicated by the Message ID and source endpoint)".

So even if a recipient is not RFC 3542-challenged, the problem would be still there or not?

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Friday, April 12, 2013 15:11
To: Pierre DAVID
Cc: [email-masked]
Subject: Re: [core] Message ID in draft-ietf-core-coap-14.txt

On Apr 12, 2013, at 14:10, Pierre DAVID <[email-masked]> wrote:

> - an ID generator for broadcast or multicast address B The node A may
> thus receive the same message ID (with a low probability) for a
> unicast message from N to A and for a broadcast/multicast message from
> N.

Grüße, Carsten

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 15 Apr 2013 08:32:30 +0000

> If I generate Message IDs per *destination address*, how do I deal with broadcast/multicast addresses? It can generate collisions on Message IDs.
I think the same problem could occur if a CoAP client N sends a unicast to A's global IPv6 address and also another unicast to A's link-local address, using two different message ID variables.
(Where the client might 'think' that these two requests go to different CoAP servers).

Solutions may be up to the implementations? In that case we may need to put a warning in the text about this (potential) problem.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pierre DAVID
Sent: Friday, April 12, 2013 14:10
To: [email-masked]
Subject: [core] Message ID in draft-ietf-core-coap-14.txt

Hi,

in draft-ietf-core-coap-14.txt, section 4.4 (Message Correlation), I have a problem regarding the implementation note for Message ID generation.

It is said:

If I generate Message IDs per *destination address*, how do I deal with broadcast/multicast addresses? It can generate collisions on Message IDs.

Let's take the case where I have (say on node N):
- an ID generator for unicast address A
- an ID generator for broadcast or multicast address B The node A may thus receive the same message ID (with a low probability) for a unicast message from N to A and for a broadcast/multicast message from N.

In my opinion, the Message ID can not be generated by destination address nor by prefix.

Have I missed something?

Pierre David

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Apr 2013 10:39:07 +0200

> (Where the client might 'think' that these two requests go to different CoAP servers).

Well, A wouldn't know how to send anything back then?  What source address should be on the return message?

In a 3542-challenged environment, you have to have a socket per each of your endpoint addresses, bound to that address only.
(See section 6.2 of RFC 3542 for how to do this in a modern environment.)

If that worked well enough for multicast, too, there wouldn't be a problem.

Grüße, Carsten