Subject: Re: [core] Group Communication published as RFC 7390

From: "weigengyu" <[email-masked]>
Date: Tue, 4 Nov 2014 17:00:35 +0800

Hi,

Whether the CoRE WG is interested in Reliable Group Communications.
It is required in the scenarios given by OMA.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

"Rahman, Akbar" <[email-masked]> writes:

> http://tools.ietf.org/html/rfc7390

Thanks, Akbar and Esko, for keeping up the flame on this subject!

I have seen considerable interest in making group communication over
CoAP more useful, and this document is a good first start.
I expect that more people will come to the IETF with work in this area.

Gruesse, Carsten

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 4 Nov 2014 12:34:36 +0000

Hi Gengyu,

Can you give some more description of why you think this is required?  Can you give a reference to a section in the OMA LWM2M spec where they reference reliable group communications?

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

I have seen considerable interest in making group communication over CoAP more useful, and this document is a good first start.
I expect that more people will come to the IETF with work in this area.

Gruesse, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Tue, 4 Nov 2014 22:14:54 +0800

Hi Akbar,

In the use cases B.1 and B.2 requirements are to turn on/off a specific 
swtich or a group of switches.
We believe that reliable communications are required for turning on/off 
electrical switches.

The following words are from an OMA document.

Lightweight Machine to Machine Requirements
Candidate Version 1.0 – 02 Oct 2012

Appendix B. Use Cases (Informative)
B.1 Streetlight Control
B.1.1 Short Description
John is a streetlights supervisor – responsible to manage streetlights 
system at his home town. There are thousands of
streetlights in the city and he expects to have low-cost M2M sensors 
embedded in these streetlights. He needs a capability to
remotely turn on/off a specific streetlight or a group of streetlights. He 
needs a capability to know the control status of each
streetlight. He needs a capability to make sure that remote instructions 
sent to these streetlights are only accepted from
authorized users (such as himself).

B.2 Air Condition
B.2.1 Short description
Ted is a HVAC supervisor – responsible to manage air-conditioning systems 
at his multi-story corporate office. There are
multiple air-conditioning systems in his office for full HVAC support. He 
expects to have low-cost M2M sensors embedded
in these HVAC systems. He needs a capability to remotely turn on/off a 
specific air conditioning system or a group of
systems. He needs a capability to specify the air-conditioning system to 
provide its metering data. He needs a capability to
configure the temperature threshold for turning on/off the air-conditioning 
systems.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Rahman, Akbar
Sent: Tuesday, November 04, 2014 8:34 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

Can you give some more description of why you think this is required?  Can 
you give a reference to a section in the OMA LWM2M spec where they reference 
reliable group communications?

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

I have seen considerable interest in making group communication over CoAP 
more useful, and this document is a good first start.
I expect that more people will come to the IETF with work in this area.

Gruesse, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 5 Nov 2014 04:42:43 +0000

Hi Gengyu,

Thank you for the references and the discussion.

>We believe that reliable communications are required for turning on/off electrical switches.

Yes, but there are also other alternatives including what was identified in RFC 7390 Section 2.4:

	2.4. RESTful Methods

   	Group communication most often uses the idempotent CoAP methods GET
   	and PUT.  The idempotent method DELETE can also be used.  The non-
   	idempotent CoAP method POST may only be used for group communication
   	if the resource being POSTed to has been designed to cope with the
   	unreliable and lossy nature of IP multicast.  For example, a client
   	may resend a multicast POST request for additional reliability.  Some
   	servers will receive the request two times while others may receive
   	it only once.  For idempotent methods, all these servers will be in
   	the same state while for POST, this is not guaranteed; so, the
   	resource POST operation must be specifically designed to take message
   	loss into account.

	http://tools.ietf.org/html/rfc7390#section-2.4

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2014 9:15 AM
To: Rahman, Akbar; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

In the use cases B.1 and B.2 requirements are to turn on/off a specific swtich or a group of switches.
We believe that reliable communications are required for turning on/off electrical switches.

Lightweight Machine to Machine Requirements Candidate Version 1.0 – 02 Oct 2012

Appendix B. Use Cases (Informative)
B.1 Streetlight Control
B.1.1 Short Description
John is a streetlights supervisor – responsible to manage streetlights system at his home town. There are thousands of streetlights in the city and he expects to have low-cost M2M sensors embedded in these streetlights. He needs a capability to remotely turn on/off a specific streetlight or a group of streetlights. He needs a capability to know the control status of each streetlight. He needs a capability to make sure that remote instructions sent to these streetlights are only accepted from authorized users (such as himself).

B.2 Air Condition
B.2.1 Short description
Ted is a HVAC supervisor – responsible to manage air-conditioning systems at his multi-story corporate office. There are multiple air-conditioning systems in his office for full HVAC support. He expects to have low-cost M2M sensors embedded in these HVAC systems. He needs a capability to remotely turn on/off a specific air conditioning system or a group of systems. He needs a capability to specify the air-conditioning system to provide its metering data. He needs a capability to configure the temperature threshold for turning on/off the air-conditioning systems.

Regards,

Gengyu WEI
-----原始邮件-----
From: Rahman, Akbar
Sent: Tuesday, November 04, 2014 8:34 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Gruesse, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 6 Nov 2014 00:15:00 +0800

Hi Akbar,

RFC7390 is important and useful for many application.
But  it does not meet the requirements  as OMA specifies.
The application requiring the gurranteed reliable group communications has 
to handle the reliability issue by itself.

Suppose that OMA's applications are common in the future,
it might be a better alternative to have CoAP with the garanteed reliable 
group communication facility.

Best Regards,

Gengyu WEI
-----原始邮件----- 
From: Rahman, Akbar
Sent: Wednesday, November 05, 2014 12:42 PM
To: weigengyu
Cc: [email-masked] ; Carsten Bormann
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

>We believe that reliable communications are required for turning on/off 

Yes, but there are also other alternatives including what was identified in 
RFC 7390 Section 2.4:

2.4. RESTful Methods

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 9:15 AM
To: Rahman, Akbar; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

Lightweight Machine to Machine Requirements Candidate Version 1.0 – 02 Oct 
2012

Appendix B. Use Cases (Informative)
B.1 Streetlight Control
B.1.1 Short Description
John is a streetlights supervisor – responsible to manage streetlights 
system at his home town. There are thousands of streetlights in the city and 
he expects to have low-cost M2M sensors embedded in these streetlights. He 
needs a capability to remotely turn on/off a specific streetlight or a group 
of streetlights. He needs a capability to know the control status of each 
streetlight. He needs a capability to make sure that remote instructions 
sent to these streetlights are only accepted from authorized users (such as 
himself).

B.2 Air Condition
B.2.1 Short description
Ted is a HVAC supervisor – responsible to manage air-conditioning systems 
at his multi-story corporate office. There are multiple air-conditioning 
systems in his office for full HVAC support. He expects to have low-cost M2M 
sensors embedded in these HVAC systems. He needs a capability to remotely 
turn on/off a specific air conditioning system or a group of systems. He 
needs a capability to specify the air-conditioning system to provide its 
metering data. He needs a capability to configure the temperature threshold 
for turning on/off the air-conditioning systems.

Regards,

Gengyu WEI
-----原始邮件-----
From: Rahman, Akbar
Sent: Tuesday, November 04, 2014 8:34 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Gruesse, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 5 Nov 2014 16:28:36 +0000

Thanks, Gengyu.

It would be good to also hear Zach's opinion on this as he was active in the development of the LWM2M spec.  Also Carsten is very knowledgeable about multicast in general.

Zach/Carsten - Can you give your opinion on Gengyu's interpretation of OMA multicast requirements?

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: Wednesday, November 05, 2014 11:15 AM
To: Rahman, Akbar
Cc: [email-masked]; Carsten Bormann
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

RFC7390 is important and useful for many application.
But  it does not meet the requirements  as OMA specifies.
The application requiring the gurranteed reliable group communications has to handle the reliability issue by itself.

Suppose that OMA's applications are common in the future, it might be a better alternative to have CoAP with the garanteed reliable group communication facility.

Best Regards,

Gengyu WEI
-----原始邮件-----
From: Rahman, Akbar
Sent: Wednesday, November 05, 2014 12:42 PM
To: weigengyu
Cc: [email-masked] ; Carsten Bormann
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

2.4. RESTful Methods

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 9:15 AM
To: Rahman, Akbar; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

B.2 Air Condition
B.2.1 Short description

Regards,

Gengyu WEI
-----原始邮件-----
From: Rahman, Akbar
Sent: Tuesday, November 04, 2014 8:34 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Gruesse, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 11 Nov 2014 09:54:51 +0000

Hi Akbar, Gengyu,

As typical in many standards it starts with a wide range of use cases. In the end not all these cases can be supported because trade-offs have to be made, or because a person/company pushing the use case is not participating. So I do not think special effort was done in LWM2M to support an authorization+multicast use case. And many cellular communication networks may not have IP multicast enabled.

From my work background I can confirm that for the use case of streetlight control, both individual control and group control is required. Group control can be implemented using multicast or serial unicast. Multicast has some advantages (lower traffic from controller node, lower latency, better synchrony). However, security (integrity, replay protection, sometimes authentication) is typically required for such multicast control - which current CoAP multicast can't provide. For more information see the discussion on https://tools.ietf.org/html/draft-keoh-dice-multicast-security-08 which aims to adapt DTLS to be suitable for CoAP multicast.

Regards
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Wednesday, November 05, 2014 17:29
To: weigengyu; Carsten Bormann; Zach Shelby
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Thanks, Gengyu.

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 05, 2014 11:15 AM
To: Rahman, Akbar
Cc: [email-masked]; Carsten Bormann
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

Best Regards,

Gengyu WEI
-----原始邮件-----
From: Rahman, Akbar
Sent: Wednesday, November 05, 2014 12:42 PM
To: weigengyu
Cc: [email-masked] ; Carsten Bormann
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

2.4. RESTful Methods

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 9:15 AM
To: Rahman, Akbar; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

B.2 Air Condition
B.2.1 Short description

Regards,

Gengyu WEI
-----原始邮件-----
From: Rahman, Akbar
Sent: Tuesday, November 04, 2014 8:34 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,

Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Group Communication published as RFC 7390

Gruesse, 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: Carsten Bormann <[email-masked]>
Date: Tue, 11 Nov 2014 06:13:49 -1000

> Zach/Carsten - Can you give your opinion on Gengyu's interpretation of OMA multicast requirements?

I cannot speak to the OMA requirements.

Esko has already mentioned the security considerations; we have had many good discussions about those in DICE, and with the progress in yesterday’s meeting, it is conceivable that DICE will come up with a workable solution for both group and source authentication.  The handling of the group keys can be performed in a multi-unicast setup protocol protected by DTLS, or using object security (e.g., COSE).  So I’ll consider this part as covered.

Re reliability:  Clearly, there are applications where one would want to benefit from the latency advantages of multicast but also achieve reliable transfer.  Reliable multicast is an entire discipline on its own, with a significant body of work.  In the IETF, we have a standardized reliable multicast protocol: NORM (RFC 5401/5740).  (There is also ALC/FLUTE, but this is more about multicasting media streams.)  One fundamental challenge is that a sender can never be sure that a group member did not drop out completely without receiving a positive ACK from that member (possibly aggregated via some other member or the routing infrastructure).  NORM can somewhat amortize that over multiple packets, using negative acknowledgements, if it is OK to have some delay in achieving reliability.  But if the entire communication is “switch on”, there is nothing to amortize — the one forward multicast will need to be affirmed by reverse unicast acknowledgments, hopefully paced in such a way as to not cause an implosion.  Multiple copies of the forward multicast (“saturation”) can reduce the number of unicast repair retransmission required, achieving good reliability.  Router supported transport similar to that provided by MPL can also be used to further increase delivery probability of the forward multicast.  But if it needs to be “reliable”, positive ACKs from each group member are required.  Aggregating those somewhat might be a relatively inexpensive form of router support that could be added to a routing protocol such as RPL.

Grüße, Carsten