locked
cloud-to-device / device-to-cloud message rate limits asymmetry RRS feed

  • Question

  • We have a scenario where many IoT devices need to be controlled remotely, possibly using a personal assistant. In this use case, devices do not send much data to the cloud, it is mainly a cloud-to-device scenario. Commands may originate from direct user interaction with the product and user expects devices to react with minimal latency (subject to network conditions). Commands need not to be stored and direct feedback of the result would be nice.

    Notice that messages may be directed to different devices at the same time, and while perfect sync is not required, we can't afford a 20 seconds delay if 20 messages are to be sent.

    Referring to this document it seems that maximum cloud-to-device rate per unit is quite low, about 1.6 messages per second per unit. Considering the multi tenancy nature of our product, it seems that cloud-to-device communication may require an insane number of units just to send 100 messages per second. Am I missing something?

    As a side note, do direct messages change something in this scenario? They seem to have a different limits but the difference is not detailed in all comparisons between direct and cloud-to-device messaging comparisons.

    Thanks!


    Friday, November 9, 2018 10:41 AM

Answers

  • Thanks for details.

    1. Using a Direct Method required to use a connection oriented protocol such as MQTT and AMQP protocols supported by Azure IoT Hub.

    2. Cloud-to-device messaging is an asynchronously disconnectable (queuing) one way message exchange pattern

    3. Azure IoT Hub doesn't have a broadcasting messages to the multiple device, the workaround can be use a IoT Hub job to deliver messages to the multiple devices, but the number of jobs running concurrently is limited

    4. Based on your description, the best choice is to use an Azure IoT Hub with starting S2 scale tier and MQTT device protocol for enabling a Direct method communications. Scaling Out and Up you can handle a throttling limits. Of course, scaling will cost more, but that is the model of the Azure IoT Hub.

    5. Direct methods throttling is: 24MB/sec/unit (for S3), 480KB/sec/unit (for S2), 160KB/sec/unit (for S1) based on 8kB throttling meter size, so for S2 you can handle ~60messages/sec/unit.

    - the most common Microsoft Azure limits: https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits

    My previously comment for using an Azure SignalR Service was based on your scaling price consideration, it was a compromise for using a scale B1 (just only a telemetry data injection) + SignalR Service for device notification + connection less oriented protocol (https).

    Thanks

    Roman

       





    Tuesday, November 13, 2018 11:28 AM

All replies

  • Hello MB_Bytech,

    Can you let us know which document are you reading this info from?

    Thanks!

    Monday, November 12, 2018 11:59 AM
  • Hi,

    please check this document:

    https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling

    Under "operation throttles" table, row 4 is:

    Cloud-to-device sends | 1.67/sec/unit (100/min/unit) | 1.67/sec/unit (100/min/unit) | 83.33/sec/unit (5000/min/unit)

    If I am not wrong, it means that the service may throttle if more than 1.67 messages are sent per unit per second. B3 and S3 somewhat improve the situation, but at a higher cost. In any case, there is a huge disparity between device-to-cloud and cloud-to-device values. In some scenarios, cloud-to-device are more or similarly important to device-to-cloud.

    Regards.

    Monday, November 12, 2018 12:26 PM
  • Hi MB_Bytech,

    - the Azure IoT Hub is not a generic communication broker. It is a secured and manageable IoT HuB gateway for injection a telemetry data from the devices to the cloud stream pipeline in the the real-time manner. However, the Azure IoT Hub offers also opposite async and sync communications with a device based on some limitations and throttling, for example:

    Maximum delivery count for cloud-to-device messages        100

    Cloud-to-device sends 83.33/sec/unit (5000/min/unit) (for S3), 1.67/sec/unit (100/min/unit) (for S1 and S2)       
    Direct methods      

          24MB/sec/unit (for S3), 480KB/sec/unit (for S2), 160KB/sec/unit (for S1)
         

        

    As you can see the above throttling, based on your needs you can Scale Up (from S1, S2, S3) and/or Scale Out using more units.

    Based on your devices, the other option can be used for your solution to add an Azure SignalR Service for "heavy cloud-to-device communications" which it can be used for broadcasting, group oriented and single user sync notifications close to the real-time.   

    Thanks

    Roman





    • Edited by Roman Kiss Monday, November 12, 2018 3:19 PM
    Monday, November 12, 2018 3:15 PM
  • Azure SignalR Service is an interesting solution but I believe that in your situation (you can't accept huge delay, commands need not to be stored and direct feedback of the result would be nice) you would want to use Direct Methods. 

    "Direct methods represent a request-reply interaction with a device similar to an HTTP call in that they succeed or fail immediately (after a user-specified timeout). This approach is useful for scenarios where the course of immediate action is different depending on whether the device was able to respond."

    From: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-direct-methods

    Using direct methods would allow you to maintain all the management on a single place (IoTHub) when compared with Azure SignalR Service.

    Would also advise you to read the Azure IoT Reference Architecture Guide.

    Thanks.

    Monday, November 12, 2018 4:38 PM
  • Thanks you both for taking time to answer.

    I while I do understand that IoT hub is not a message broker, it is not proposed as an injection solution only. It is Azure's solution for connecting IoT devices, I was just pointing out that while injection of data is probably the most common use case, it is not the only one.

    Awesome as it is, I think that scaling out is not properly addressing my need. Probably IoT hub is not the best fit, but then, let's reverse it. Which Azure product is a massive message broker with minimal latency and 1:1 cloud/device or cloud/client, client/client (through cloud) ratio? SignalR is a nice product, but is nowhere nearly scalable as IoT hub is (1000 connections per unit?). Maybe I am missing some product (there are so many new ones every few months)?

    Tuesday, November 13, 2018 9:25 AM
  • Azure SignalR Service is an interesting solution but I believe that in your situation (you can't accept huge delay, commands need not to be stored and direct feedback of the result would be nice) you would want to use Direct Methods. 

    "Direct methods represent a request-reply interaction with a device similar to an HTTP call in that they succeed or fail immediately (after a user-specified timeout). This approach is useful for scenarios where the course of immediate action is different depending on whether the device was able to respond."

    From: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-direct-methods

    Using direct methods would allow you to maintain all the management on a single place (IoTHub) when compared with Azure SignalR Service.

    Would also advise you to read the Azure IoT Reference Architecture Guide.

    Thanks.

    Hi, can you confirm that there are no strict throttling or messages/unit limits with Direct Messages aside from KB/sec/unit bandwidth? If so, this is the solution I am looking for.

    Thanks!

    Tuesday, November 13, 2018 9:28 AM
  • Could you describe your IoT device side such as number of devices, connection protocol, platform, …

    Thanks

    Roman




    • Edited by Roman Kiss Tuesday, November 13, 2018 10:14 AM
    Tuesday, November 13, 2018 10:11 AM
  • Could you described your IoT device side such as number of devices, connection protocol, platform, …

    Thanks

    Roman



    Our IoT devices are Linux/ARM based with full networking capability, hosting our node.js based app. At the moment we are using HTTPS for ingestion and polling, but looking forward to our expansion scenario and features we'd like to add, we need something more suited. Notice that while we need a low latency command (cloud to device, one to many) and generic notification (device to cloud, one to one) messaging, we are also doing data ingestion (and IoT hub is perfectly suited for that. We'd like to keep everything under the same umbrella), also device twins, firmware upgrades etc are a nice plus of the IoT Hub. The only thing we need from IoT Hub is capacity to send messages to multiple device groups at (nearly) the same time.

    Number of devices: at the moment, a few hundreds (slightly more than prototype installations) so Azure SignalR would be ok and at the moment we are just experimenting. But designing for the future would be nice and IoT hub seems the right way to go for future growth, considering we can buy more and more units and all extra features aside from data ingestion.

    We can of course also consider SignalR and it would be a good solution for medium term, but again my question arose because IoT Hub would be a better match.

    Tuesday, November 13, 2018 10:25 AM
  • Thanks for details.

    1. Using a Direct Method required to use a connection oriented protocol such as MQTT and AMQP protocols supported by Azure IoT Hub.

    2. Cloud-to-device messaging is an asynchronously disconnectable (queuing) one way message exchange pattern

    3. Azure IoT Hub doesn't have a broadcasting messages to the multiple device, the workaround can be use a IoT Hub job to deliver messages to the multiple devices, but the number of jobs running concurrently is limited

    4. Based on your description, the best choice is to use an Azure IoT Hub with starting S2 scale tier and MQTT device protocol for enabling a Direct method communications. Scaling Out and Up you can handle a throttling limits. Of course, scaling will cost more, but that is the model of the Azure IoT Hub.

    5. Direct methods throttling is: 24MB/sec/unit (for S3), 480KB/sec/unit (for S2), 160KB/sec/unit (for S1) based on 8kB throttling meter size, so for S2 you can handle ~60messages/sec/unit.

    - the most common Microsoft Azure limits: https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits

    My previously comment for using an Azure SignalR Service was based on your scaling price consideration, it was a compromise for using a scale B1 (just only a telemetry data injection) + SignalR Service for device notification + connection less oriented protocol (https).

    Thanks

    Roman

       





    Tuesday, November 13, 2018 11:28 AM
  • Roman, thanks for your help.

    1. Exactly what I needed!

    3. I can handle multiple sends from my backend

    Is there a pub/sub service with low latency and high scalability for IoT in Azure? I just gave a quick look at Google's cloud pubsub service and it seems very favorable in terms of message rate, limits and pricing.

    Wednesday, November 14, 2018 3:16 PM