DDS11 — Additional_qos_THROUGHPUT Issue

Issue# 2110 Additional_qos_THROUGHPUT Issue [Boeing SOSCOE] ? The DDS specification has no provision to control the amount of bandwidth that the different entities can consume. ? Ideally the user of the DDS API could indicate bandwidth limits and also reserve bandwidth in a way that could then be mapped by the service into the underlying transport facilities, for the cases where those facilities are there. ? At a minimum the user would like to indicate bandwidth limits in bytes per second. Although low level, this kind of unit would make more sense than something like messages-per-second because each data-type, or maybe even each particular write to an instance may be of a different size. ? There is also the case where the communication infrastructure needs to communicate to the application how much bandwidth it can expect to have. This can also change dynamically based on current network conditions. The application can then take advantage of this knowledge to configure itself so that only the more important messages are sent. ? All we need is something that can be passed to the API; the middleware does not need to do anything with it. ? Not clear how it can be implemented or how it interacts with things. But there is a requirement that there is a way to specify this QoS. This comes from streaming type applications. They want to be able to reserve some bandwidth.

Proposal [Boeing SOSCOE] ? No concrete action is proposed at this time. The precise definition is fairly involved. However there is a general desire to be able to allocate and control bandwidth utilization so it would be nice if approaches would be explored. Comment [RTI] ? The fundamental problem is how to map this to the DDS model. The DDS spec. does not have a model for the Transport or expose to the user which entities (writers / readers) are associated with each transport. It is in fact possible that a single write to an Entity may result on multiple messages each over a different transport, its all hidden from the application. ? So the first thing would be to introduce some model on how the entities interact with the transport. Where are the TranportPlugins installed (globally, per participant, per Connector), what are the transport “resources” (e.g. in RTI’s TPI the SendResource, and ReceiveResource) and how they map to the DDS entities. ? Introducing a QoS that limits the bandwidth used by each DataWriter would be straightforward. Similarly for a QoS that attempts to reserve certain amount of bandwidth for a particular DataWriter. The DDS implementation who knows what transports it is associated with would then map it to the appropriate transport calls. The problem is that it would apply indiscriminately to all transports. ? For the case of EndpointConnectors if transports were explicitly associated with the connector, then it may also be possible to set this kind of QoS. It would then apply to all the DataReaders and DataWriters in the EndpointConnector. ? Regarding the listeners, presumably the callbacks would refer to the bandwidth changes on each transport resource. So for the user of the DDS API to make sense of this they would need that mode/map to DDS entities.