[zeromq-dev] QoS support

[Martin Sustrik]

Hi Erich,

> Sorry I should have revised my statements better, I hope this clears 
> them up. 

This is pretty interesting scenario. I have no experience with 
industrial automation whatsoever, so your insight is very valuable...

> For 1. imagine a complex distributed control system. there are multiple 
> hosts on the network, each with sensor inputs.  Values may be considered 
> critical, important, or nice to have. The application(s) which run on 
> each host deal with raw sensor input and determine how important a value 
> is, as do "centralized" monitoring applications (control rooms, or wide 
> area algorithms). The general domain modeling relies on sensor names in 
> such cases.  Subscriptions to individual sensors come and go, and as 
> mentioned above the priority of those may be in flux as well.
> 
> In such a case app writing becomes much easier if the application can do 
> subscription and publishing based on sensor names, and do priority with 
> a simple modification to "send message" parameters. An alternative would 
> be to have 3 connections corresponding to importance, and embed the 
> sensor name in the message. The former case is harder to administer with 
> external QoS parameter tuning, as there would need to be all sorts of 
> deep packet inspection, on many connections. The latter would require 
> much more consideration from the application writers, potentially 
> including their own priority queueing.  Basically my position is that 
> since this is a control network, and therefore the hosts are pretty well 
> trusted, we can make a smart middleware to do the QoS params, and trust 
> it at the routers (i.e. the first solution).

Ok. There are producers producing messages with different priorities, 
however, all messages are published to the same topic hierarchy. You are 
right, there's no way to implement such scenario using 0mq without a 
need to create a separate transport for each priority level.

I must admit I have no straightforward answer at the moment. Do you have 
any idea of how the thing should be implemented?

One more question: Can you think of a scenario where there's large 
number of priority levels? Say 256? Or 10000? The point is that it's 
rather acceptable to have 3 connections per feed, however, it's not 
acceptable to have 10000 of them.

> Point 2, is a slightly different take on the same notion. It assumes 
> that some applications will not partake in the system QoS of their own 
> accord. In such cases, some QoS mechanisms on the host will go a long 
> way. Say in the example above there is an app that aggregates security 
> video feeds and sends them along the network. For whatever reason this 
> app runs on the same box as the control apps (its a beefy box at a small 
> plant or something). The video system doesn't do QoS with the control 
> system. So we need to have host based QoS here, with priority queueing 
> making the video a lower priority via system intervention. The video may 
> or may not be tagged on egress, that is a separate issue, what we are 
> doing here is providing a guarantee to the the control system that it 
> will be able to do its own thing correctly.  Further say each individual 
> sensor and camera steam comes in on the LAN. We need ingress controls to 
> prioritize handling of sensor data over video data. 

Right. What's the part that's not doable by configuring host firewall 
and switch?

Martin