I just want to mentioned that how ping/pong or CSM should be triggered instead of how detail it should respond for each request.
Shortly it could be overall sequence guideline from OCF cloud interaction perspective. AFAIK, Regarding /oic/ping resource, there was a discussion for the change from OCF spec after OIC spec to use CoAP over TCP signaling mechanism instead of /oic/ping resource. BR, Uze Choi From: Scott King [mailto:scott.k...@fkabrands.com] Sent: Friday, November 02, 2018 3:17 AM To: Ondrej Tomcik; 최우제 (Uze Choi); 'John Zhang'; yitzc...@coapp.co.il; 'IoTivity Developer List' Subject: RE: [dev] Maintaining a connection from Coap devices to the iotivity cloud Typing responses in prior emails in the chain tends to make things unreadable on mobile, so pardon the copy pastes. It seems like a big motivation for these disagreements is a difference in use cases. Ondrej is working on industrial sensors, so his required SLA is very different than my employer (and presumably Samsung) where the price points are lower and SLA’s are less stringent. In a consumer electronics use case, the most important things are “just working” and not bothering the end user. While a factory operator may want the redundancy of a stack light notification and push notification when the sensor gets disconnected, and be willing to pay the extra cloud hosting costs to get that feature, it’s pretty uncommon for consumer electronics to provide that functionality. Regarding Ping-pong I have a little bit different use case. Connection can be monitored by API which Ondrej showed in the previous mail. With this device can reconnect into cloud again. Cloud can set the policy that device should regularly send the ping message (regardless of CoAP over TCP signaling or resource request) to make sure the device is healthy. Set the policy in the current implementation means – resource /oic/ping hosted by cloud itself (what is wrong because as written in the specification, OCF Cloud acts as the simple proxy, hosting resource directory. It’s not the server which should host its own resources) provides ping configuration, which devices reads right after connecting to the OCF Cloud. This mechanism shouldn’t be used at all. [scott] the OCF cloud spec already talks about hosting oic/sec/account, oic/sec/session, oic/rd and oic/sec/tokenrefresh resources so it doesn’t seem like the biggest stretch to add the oic/ping resource too. The iotivity cloud wiki page has a diagram that describes some sensible behavior for how to implement this (assuming device is the client and cloud is the server). Also, it’s a tad strange that oic/ping isn’t mentioned anywhere in the specs despite its importance and having been in the codebase since 2016. <https://wiki.iotivity.org/iotivity_cloud> https://wiki.iotivity.org/iotivity_cloud <https://wiki.iotivity.org/_media/ex1_keepalive_for_coap_over_tcp.png?w=300&tok=527f3d> https://wiki.iotivity.org/_media/ex1_keepalive_for_coap_over_tcp.png?w=300&tok=527f3d Cloud send the ping message,.. This is very strange… considering Cloud connection. Can you explain more why it is strange? Regarding RFC 8323 -> Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical Token in response. There isn’t specified who is responsible to do send the ping. Whoever can send the ping, but recipient should response as soon as practical. Both parties can send ping in parallel and expect the result. In my opinion, the one who is interested if the device is there should send the ping and expect the pong. If the device will send the ping and backend won’t reply, what this information will be used for? Take it from cloud side, device is there when it responds with reasonable time for ping. If not, device is marked as offline and user of the system is informed that device is not available. [scott] I agree with Uze that it would be strange for cloud=>device ping to be a default behavior. If the device pings the cloud and doesn’t get a response, then the device can attempt to reconnect, or at the very least change the value of its “clec” resource. If the cloud pings the device and doesn’t get a response, there is nothing the cloud can do to fix the connection. At least as default behavior, it would seem better to only have the device do pings, optionally have a “device shadow” with a timestamp kept by the cloud and then have the cloud lazily determine if the device non-gracefully disconnected when the cloud tries to route a message to the device. MQTT also seems to focus on keepalive/ping messages being initiated by the client* and that was originally designed for oil pipeline sensors sending data over unreliable networks. If you want the cloud to proactively detect when a device gets disconnected (which is probably very useful to you) then maybe it’s best to run a separate application that interfaces with your OCF cloud interface to ping the device? That could be a valuable, but optional, component of the OCF cloud codebase. * https://www.hivemq.com/blog/are-your-mqtt-applications-resilient-enough/ * https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over The other point for OCF TCP spec I’d like to say. CSM signaling, (CSM is the spec on the coap over tcp to handshake the capability of max send size and BTW.) >From the spec, 7.01 | CSM | <https://tools.ietf.org/html/rfc8323> RFC >8323 “One CSM MUST be sent by each endpoint at the start of the Transport >Connection.” from the spec. When the device connect to the Cloud, it will start the make the session and setup the tls, then device should send the CSM message and Cloud should send back the CMS message as handshake as far as CoAP over TCP spec. intends. But there is no clear comment how to use it CoAP over TCP spec. Furthermore, I cannot make sure whether cloud also should send the CMS message. It is mentioned, in the sentence you sent. There is no rule for this in detail in OCF as of now. One CSM MUST be sent by each endpoint at the start of the Transport Connection. For me this means that both parties have to send CSM at the start of the Transport Connection. But this is CoAP topic, not OCF. I believe for the feasible interoperability, these also need to be clearly defined in OCF domain at least. [scott] @Uze I 100% agree that these specs need to be more clearly defined. While the spec does say that devices which send/receive larger payloads should support blockwise, there’s no mention that the device should have CSM messages indicating blockwise support and max-message-size . There should also be explicit call outs in the cloud spec about using release, hold-off and abort messages when a server becomes overloaded. From: iotivity-dev@lists.iotivity.org [mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Ondrej Tomcik Sent: Thursday, November 1, 2018 5:56 AM To: 최우제 (Uze Choi) <uzc...@samsung.com>; 'John Zhang' <zha...@oppo.com>; yitzc...@coapp.co.il; 'IoTivity Developer List' <iotivity-dev@lists.iotivity.org> Subject: Re: [dev] Maintaining a connection from Coap devices to the iotivity cloud Hello! Ondrej Tomcik :: KISTLER :: measure, analyze, inovate From: 최우제 (Uze Choi) <uzc...@samsung.com> Sent: Donnerstag, 1. November 2018 09:50 To: 'John Zhang' <zha...@oppo.com>; Tomcik Ondrej <ondrej.tom...@kistler.com>; yitzc...@coapp.co.il; 'IoTivity Developer List' <iotivity-dev@lists.iotivity.org> Subject: RE: [dev] Maintaining a connection from Coap devices to the iotivity cloud Hi All, Regarding Ping-pong I have a little bit different use case. Connection can be monitored by API which Ondrej showed in the previous mail. With this device can reconnect into cloud again. Cloud can set the policy that device should regularly send the ping message (regardless of CoAP over TCP signaling or resource request) to make sure the device is healthy. Set the policy in the current implementation means – resource /oic/ping hosted by cloud itself (what is wrong because as written in the specification, OCF Cloud acts as the simple proxy, hosting resource directory. It’s not the server which should host its own resources) provides ping configuration, which devices reads right after connecting to the OCF Cloud. This mechanism shouldn’t be used at all. Cloud send the ping message,.. This is very strange… considering Cloud connection. Can you explain more why it is strange? Regarding RFC 8323 -> Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical Token in response. There isn’t specified who is responsible to do send the ping. Whoever can send the ping, but recipient should response as soon as practical. Both parties can send ping in parallel and expect the result. In my opinion, the one who is interested if the device is there should send the ping and expect the pong. If the device will send the ping and backend won’t reply, what this information will be used for? Take it from cloud side, device is there when it responds with reasonable time for ping. If not, device is marked as offline and user of the system is informed that device is not available. However, there is no such a rule in OCF unfortunately. Not sure if something like this has to be in the OCF specification. If we would go with custom mechanism - protocol independent healtcheck, yes it has to be there. But I would start simply. The other point for OCF TCP spec I’d like to say. CSM signaling, (CSM is the spec on the coap over tcp to handshake the capability of max send size and BTW.) >From the spec, 7.01 | CSM | <https://tools.ietf.org/html/rfc8323> RFC >8323 “One CSM MUST be sent by each endpoint at the start of the Transport >Connection.” from the spec. When the device connect to the Cloud, it will start the make the session and setup the tls, then device should send the CSM message and Cloud should send back the CMS message as handshake as far as CoAP over TCP spec. intends. But there is no clear comment how to use it CoAP over TCP spec. Furthermore, I cannot make sure whether cloud also should send the CMS message. It is mentioned, in the sentence you sent. There is no rule for this in detail in OCF as of now. One CSM MUST be sent by each endpoint at the start of the Transport Connection. For me this means that both parties have to send CSM at the start of the Transport Connection. But this is CoAP topic, not OCF. I believe for the feasible interoperability, these also need to be clearly defined in OCF domain at least. BR, Uze Choi From: <mailto:iotivity-dev@lists.iotivity.org> iotivity-dev@lists.iotivity.org [ <mailto:iotivity-dev@lists.iotivity.org> mailto:iotivity-dev@lists.iotivity.org] On Behalf Of John Zhang Sent: Thursday, November 01, 2018 12:11 PM To: Ondrej Tomcik; <mailto:yitzc...@coapp.co.il> yitzc...@coapp.co.il; IoTivity Developer List Subject: Re: [dev] Maintaining a connection from Coap devices to the iotivity cloud Hi Ondrej, I have a quick question below. BR, John _____ <mailto:zha...@oppo.com> zha...@oppo.com From: <mailto:ondrej.tom...@kistler.com> Ondrej Tomcik Date: 2018-11-01 03:52 To: <mailto:yitzc...@coapp.co.il> yitzc...@coapp.co.il; <mailto:iotivity-dev@lists.iotivity.org> iotivity-dev@lists.iotivity.org Subject: Re: [dev] Maintaining a connection from Coap devices to the iotivity cloud ________________________________________ From: <mailto:iotivity-dev@lists.iotivity.org> iotivity-dev@lists.iotivity.org [iotivity-dev@lists.iotivity.org] on behalf of <mailto:yitzc...@coapp.co.il> yitzc...@coapp.co.il [yitzc...@coapp.co.il] Sent: 31 October 2018 19:16 To: <mailto:iotivity-dev@lists.iotivity.org> iotivity-dev@lists.iotivity.org Subject: Re: [dev] Maintaining a connection from Coap devices to the iotivity cloud On Wed, Oct 31, 2018 at 03:26 AM, Ondrej Tomcik wrote: What do you need such an often keep alive exchange for? If a connection breaks, the Coap device will no longer receive requests. Therefore I need it to try to reconnect as soon as this happens. The only existing mechanism I am aware of telling if the connection is broken is via the PING/PONG mechanism. -> yes, thats what ping pong is for. In case the connection was not closed gracefuly, you are waiting for a tcp timeout. If you want to know if the device is online, thats the only way. But you have to consider your requirements, how accurate information about the device status has to be? Additionaly, you should introduce timeouts for your requests. So not only ping the device every 5 seconds, what is actually a bad idea, but handle also request timeouts and flag the device as not reachable for example. Its your business logic, based on your requirements and SLAs. What kind of load? Not necessarily a specific load, but assuming an IOT cloud with thousands or more devices, I will expect the devices themselves to initiate the ping instead of the gateway, in order to take of some load from the gateway, but I guess this point is not clearcut. What is the purpose of the ping pong? To provide an accurate information if the device is there ( and delay statistics for example, ... ). Who is interested if the device is there? Cloud user. Who owns information if the device is online? Cloud. Cloud is the one who owns and maintains this information. Cloud should be responsible to ping the device to check if it is online. Device is not interested if cloud is there. You may have ping configuration per device, for some specific SLA use cases, but its cloud who has to accurately provide this information. [John] To keep the connection, do you mean the cloud should Ping the device rather than the other way around? Or either peer can send Ping message? cid:image001.gif@01D471C5.816B5CE0 Image removed by sender. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9992): https://lists.iotivity.org/g/iotivity-dev/message/9992 Mute This Topic: https://lists.iotivity.org/mt/27796570/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
