Resolving QoS Policy Configuration Challenges for

Publish/Subscribe Middleware Platforms

AFRL JBI PI Meeting

Outline

• Motivating Example

• QoS Policy Configuration Challenges

• Evaluating Common Solutions

• DQML Overview

Motivating Example – Unmanned Aerial Vehicle (UAV)

• UAV Desirable Data Flows– Storage and dissemination of

data for late arriving subscribers (e.g., other aircraft and satellites coming into range)

– Reliable communication of critical data (e.g., sensor data to satellite to ground station)

– Prioritization of data delivery for mission-critical or high value data (e.g., time-sensitive targets)

– Ordered and/or grouped data dissemination to ensure ordering and appropriate level of granularity

QoS Policy Configuration Challenges (1 of 3)

•QoS Policy Compatibility– QoS policies for the

communicating entities must be compatible between what’s requested and offered

Best effort data transfer

offered

Reliable data transfer

requested

XData will not be transferred– For example, if subscriber

requests reliable data transfer the publisher can not offer best effort data transfer

QoS Policy Configuration Challenges (2 of 3)

•QoS Policy Consistency– QoS policies for any one

entity must be consistent with each other Deadline’s period

= 5 ms.

Time based filter’s minimum separation =

10 ms.

X

QoS policies will not be set

– For example, deadline period must be >= minimum separation for time based filter

QoS Policy Configuration Challenges (3 of 3)

•Accurate QoS Policy Configuration Transformation– Propagating QoS policy

configuration through development stages

– For example, transforming design of QoS configuration into application code

Evaluating Common Solutions

•Three Common Solutions to Challenges– Point-based solutions

– Patterns-based solutions– Domain specific modeling

language (DSML) based solutions

•Categorized by – Robust vs. non-robust

solution documentation– Robust vs. non-robust

solution implementation

Point-based Solutions

• Focused on particular solution/application– QoS policy configuration is

developed• Configuration is designed

• Cons –Non-robust solution

documentation–Non-robust solution

implementation

– Application is compiled & run

– Feedback is gathered & evaluated

– Process is repeated as necessary

DesignCode

TestEvaluate

• Pros –Low overhead

• Configuration is implemented

Patterns-based Solutions

• Enables codification of configuration expertise

• Cons –No help with

solution implementation (i.e., non-robust)

• Pros –Reuse of expert

configuration design knowledge (i.e., robust design)

Continuous Data Pattern

Application A Application B Application C

• Documented use of QoS policies for– Dataflow management– Dataflow prioritization– Dataflow shaping

DSML-based Solutions

• Uses domain specific terminology and constructs

• Cons –Learning

curve/training overhead

• Pros –Robust solution

documentation (via metamodel constraints)

–Robust solution implementation (via interpreters)

Application A Application B Application C

Metamodel

QoSConfig

Application model

QoSConfig

• Metamodel created in metamodeling tool

QoS Config

DDS QoS Modeling Language (DQML 1 of 2)

• Models relevant DDS entities

• Models DDS QoS polices

• Models relationships between entities and QoS policies

DDS QoS Modeling Language (DQML 2 of 2)

• Supports QoS compatibility and consistency constraint checking

• Generates implementation artifacts (currently for DDS Benchmarking Environment (DBE))

Compicon.icoDBEInterpreter

DBEQoS Settings

DataReader

QoS SettingsDataWriter