% $Id: netqos_mde.tex 4522 2006-11-29 03:53:05Z gokhale $

\subsection{Providing Mechanisms for Specifying Network QoS Requirements}
\label{sec:NetQoSMDE}

%\begin{floatingfigure}{0.6\columnwidth}
\begin{wrapfigure}{r}{0.6\columnwidth}
%\begin{figure}[htb]
\begin{center}
%  \centering
  \vspace{-.1in}
  \mbox{\includegraphics[width=0.58\columnwidth]{figs/NetQoS}}
  \caption{Network QoS Modeling in CQML}
  \label{fig:qos-model}
\end{center}
%\end{figure}
\end{wrapfigure}
%\end{floatingfigure}

\paragraph*{Context:}
Section~\ref{sec:mw-challenges} described the need for
gathering the network QoS requirements of all the dataflows
in a DRE system to make appropriate network resource reservations
for those flows. DRE systems of interest to us are moderate to large scale,
and number of flows to be specified is in the order of thousands.

\paragraph*{Problem:}
It is infeasible for application developers to programmatically 
or manually specify the QoS needs of components and their interactions on a 
per flow basis.  Moreover, the QoS specifications are often made on 
a trial and error basis, i.e., the specification-implementation
(simulation)-testing cycle has to be repeated several times.  A
desired feature therefore is an easy to use, faster, declarative 
and scalable means of specifying these QoS requirements.  

\paragraph*{Solution Approach: Domain-specific Modeling and Generative
Programming.}
Model-Driven Engineering (MDE) is a promising approach to specify
and gather network QoS requirements for dataflows in a DRE system because
it raises the level of the abstraction of system design to a
level higher than third-generation programming languages.  Modeling
network QoS requirements and synthesizing the metadata from the model
alleviates many deployment time concerns as well as eliminates the
need for low level and potentially out of band programming.  At the
heart of our MDE approach to provision network level QoS support for
DRE systems is a platform-specific DSML for LwCCM, called
the Component QoS Modeling Language (CQML).
%%
%% JAI: Andy, do we need to following line?
%%
\iffalse
platform-specific mapping of PICML explained in
Section~\ref{sec:current}.
\fi

\paragraph*{Modeling network QoS requirements:}
CQML allows a modeler to annotate the elements modeled in CQML with
platform-specific details and QoS requirements as shown in
Figure~\ref{fig:qos-model}, in the following manner:  
%%
%% JAI: Andy, i have captured the following in a concise manner.
%% Let me know if this is OK.
%%
\iffalse
The artifacts which can be annotated
are component instances, component implementations, connections
between component ports, component assemblies, among others.  Network
QoS modeling is part of a of the larger QoS modeling capabilities of
CQML.  CQML allowes a deployer to model the network level QoS
requirements in the QoS view of the DRE system as shown in
Figure~\ref{fig:qos-model}.
The QoS view leverages the basic structure of the DRE system in terms
of the component instances in an assembly, component ports and their
inter connections.  Additionally, it captures network QoS
requirements in the following ways:
\fi

% Sumant, I tried adding a punch to the heading so as to convey how we
% are addressing the challenges we mentioned. Make sure these are the
% right way to convey things.
\begin{itemize}
 \item \textbf{Network QoS specification via annotating component
   connections.} Connections between components and component
 assemblies in a LwCCM application can be annotated with (1) one of the
 following network QoS attributes: HIGH PRIORITY (HP), HIGH
 RELIABILITY (HR), and MULTIMEDIA (MM), and (2) bi-directional bandwidth
 requirements.  The HP class represents the
 highest importance and lowest latency traffic (e.g., fire and smoke 
 incidence reporting).  The HR class represents TCP traffic requiring
 low packet drop rate (e.g. surveillance data).  The MM class involves
 large amount of traffic which can tolerate certain amount of
 packet loss, but require predictable delays (e.g video conferencing, news tickers).  
 In addition there is a default BEST EFFORT (BE) class which 
 requires no QoS treatment (e.g., email).   

 \item \textbf{Generation of deployment metadata.} The network
 QoS requirements have to be specified along with other component
 deployment-specific details (e.g. CPU requirements, connections), so
 that resource management algorithms can allocate specific hardware
 nodes to components that can satisfy multiple CPU resource
 requirements. A CQML model interpreter traverses the multiple views
 of the system, generates system deployment information, and
 reconciles network QoS details in the system deployment information,
 relieving the system deployers from the tedious and error-prone
 tasks. 
 \iffalse
 QOS annotated model of the system and synthesizes deployment metadata
 reconciling QoS information in it.  The advantage of using an
 automated process of metadata generation is that the model interpreter
 takes into account multiple views of the system and produces the
 correct descriptors thereby relieving the developer from these
 error-prone and tedious tasks. 
 \fi

 \item \textbf{Model scalability in QoS annotations.}
 Figure~\ref{fig:qos-model}
 specifies how the {\bf FireSensorAggregator} component aggregates
 fire sensor information from multiple sensors. In our modern
 office environment scenario, there could be multiple fire sensors
 deployed, and each of the sensors need to send the information
 with the same urgency, and hence the same network QoS. In order
 to facilitate the system modeler to associate the same network
 QoS across multiple connections, we follow the principle of
 "write once, deploy everywhere". We allow the modeler to define
 the QoS (in this case, the property {\bf FIRE\_HP\_QOS}) once
 and refer it across multiple connections as shown in
 Figure~\ref{fig:qos-model}. In the future, any number of fire
 sensors could be added, and the QoS can be rapidly added,
 thereby increasing the scalability of the modeling process.

 \item \textbf{Facilitating ease of deployment.} In
 Figure~\ref{fig:qos-model}, the {\bf Monitor} component could
 dictate the bandwidth reservations for all the different aggregator
 components (e.g {\bf FireSensorAggregator}) deployed in the modern
 office environment. For example, the {\bf Monitor} component could
 receive only upto 300 Kbps of data from all the aggregator components.
 This bandwidth is shared among the different hosts hosting the aggregator
 components, as sufficient reservations need to be made for sending
 data from the aggregator components to the {\bf Monitor} components. But
 at modeling time, the hosts hosting the aggregator components are not known,
 and hence the system modeler cannot specify the bandwidth reservations
 for each and every connection between the aggregator components and the
 {\bf Monitor} component. CQML facilitates the ease of modeling such
 deployments by defining the {\em bandwidth pipe} to be shared between
 the different aggregator components and the {\bf Monitor} component. The
 information about the {\em bandwidth pipe} is captured in the deployment
 metadata using the model interpreter, which then assists the RACE
 network resource allocator described in Section~\ref{sec:resource_reserve} 
 to divide the bandwidth described in the {\em bandwidth pipe}
 among the hosts hosting the aggregator components.

 \end{itemize}

 %% JAI: This is not really a scalability issue, because if the
 %% server declared model is specified, the clients cannot do much.
 %% This means that the clutter cannot happen just like that.
 %% So this example is weak. More useful example would
 %% be to say that, we define a QoS once and reference it
 %% at multiple places. Say for example, each port can have
 %% a property attached to it called the QoS. That property
 %% can be defined once, but referenced at multiple places.
 %% For example, two distinct connections in a system could
 %% of the type HR and requesting the same FWD and RVS BW REQS.
 %% In which case, you only define once but reference multiple
 %% times. 
 %% Also this bullet and the next bullet could be combined.
 %% to save space.
 %%
\iffalse
 \item \textbf{Model scalability in annotations.} Model
 scalability in CQML is achieved by providing a short 
 hand for annotating a bulk of connections simultaneously with network
 QoS attributes.  The components, which use the {\em
   server declared} model of network QoS provisioning (see
 Section~\ref{sec:policy} for more details) can have network
 QoS specification associated on a per port basis\footnote{The
 ''ports'' discussed here are not the ports in the conventional socket
 programming sense.  But instead, these are the provided and/or
 required interfaces exposed by the components.  The interfaces are
 described in the CORBA Interface Definition Language(IDL.)}. 
 The QoS attributes specified in such a way are applicable to all the
 connections from the client components that are connected to the
 annotated component port.  This representation of the port level
 network QoS minimizes the modeling work and the resulting model
 clutter because it scales independent of the number of client
 components communicating with the provider component.  For example,
 the Monitor component in the Figure~\ref{fig:qos-model} indicates
 that one of the ports has HR QoS associated with it.  The port level
 annotation is extended (automatically) to both of the connections
 from the two aggregators to the Monitor.

 \item \textbf{Model scalability via bandwidth pipe sharing.}
 CQML allows modeling of a shared bandwidth pipe among multiple
 component connections.  Multiple connections between a pair of
 components can share a bandwidth pipe among them.  Such a system
 configuration may arise in two distinct situations: (1) exactly two
 components share the pipe of bandwidth, and (2) more than two
 distributed components share the bandwidth pipe such that the
 annotated connections share a physical network element (such as an
 ingress router) in the topology.  The intent is to limit
 %\footnote{The enforcement of the limit is done at runtime by means of bandwidth 
 %reservation and policing.}
 the aggregate bandwidth used at runtime by the annotated connections to
 a maximum value.  

 In the first case, it is straightforward because
 only a single pair of hosts is involved.  In the second case though,
 where sharing of a bandwidth pipe among connections results into more
 than a unique pair of components, the deployment view of the system
 comes into play.  If the components are distributed across more than
 two hosts in the network having a common network element between
 them, then the bandwidth pipe is divided equally among the
 participating source hosts.  
 The common network element is then configured to identify the flows
 from the multiple source hosts and limit the bandwidth usage of each.  

 The following section on automatic
 generation of deployment metadata describes in detail how interaction
 of the two views of the system is taken into account while generating
 the metadata.

\paragraph*{(2) Automated synthesis of deployment metadata with
  network QoS}
\label{deployment_metadata}

The network QoS requirements have to be reconciled with the remainder
of the application details, such as the deployment and configuration
of the different components in the application.  This reconciled
information should be made available in a form that is understandable
to both the RACE planners and the DAnCE deployment engine.  A CQML
model interpreter developed as a plugin within GME traverses the
QOS annotated model of the system and synthesizes deployment metadata
reconciling QoS information in it.  The advantage of using an
automated process of metadata generation is that the model interpreter
takes into account multiple views of the system and produces the
correct descriptors thereby relieving the developer from these
error-prone and tedious tasks. 

\fi

\iffalse
% Sumant, these are too many details and I don't see a connection to
% the interpreters - andy
In our network QoS provisioning framework, bandwidth reservation and 
policing is configurable on a host to host basis. 
When connections between multiple components share
a pipe of bandwidth, this requirement has to be mapped into a set of
one or more unique pairs of hosts across the network. This brings into
the picture the deployment view of the system. At the network level,
multiple src-dest pairs of hosts sharing a bandwidth is meaningful
only when they share one or more physical network elements such as
a router. One possible strategy to split the bandwidth across multiple
hosts could be to divide it in equal parts.
\fi
\iffalse
The network QoS model interpreter maps the application level bandwidth
sharing requirements on the physical network level configuration
parameters on behalf of the system deployer. Thus, it alleviates the 
complexity of this mapping by means of automation and eliminates the 
chance of human error. As mentioned before, the model interpreter also 
helps reconcile the deployment view of the system and the network usage 
when the bandwith pipe is shared among multiple components. For example, 
as shown in the Figure~\ref{fig:qos-model}, the deployment decision of the
\textit{FireSensorAggregator} and the \textit{TemperatureAggregator}
may change over a period of time or during system testing.  Thus, the
components connected to the remote component \textit{Monitor} may or
may not be collocated, which can affect QoS provisioning.  
When they are collocated, the aggregate bandwidth usage between the 
pair of hosts is limited to 300 Kbps and if they are distributed 
across multiple  hosts then the bandwidth is divided into two equal parts. 
\fi
