% $Id: conclusions.tex 4523 2006-11-29 04:06:54Z gokhale $


\section{Concluding Remarks}
\label{sec:conclusions}

This paper describes the design and implementation of NetQoPE, 
a model-driven middleware framework that handles network QoS 
management and enforcement for component-based DRE systems. 
This work is an extension of our previous work that only considered 
host or CPU resources. The work integrates a Bandwidth Broker
into a QoS-enabled middleware framework to ensure offered load
matches with the capacity throughout the network and thereby
providing network QoS guarantees. The Bandwidth Broker leverages
DiffServ/CoS features that are commonly available in today's
routers and switches. Two accomplishments/contributions, 
in our view, stand out:
\begin{itemize}
\item Standard Lightweight CORBA Component Middleware (CCM) 
interfaces can be extended with relative ease to develop a 
scalable and flexible middleware infrastructure that can support 
marking IP header with the right DSCP codepoint determined by the 
Bandwidth Broker, the network QoS management subsystem, in an operating 
system independent portable and in application-transparent manner, i.e., 
application developers cam be shielded from working with low level network 
interfaces. More importantly, the resultant QoS-enabled middleware facilitates 
different QoS guarantees to the same software written and deployed under 
multiple deployment targets and network environments. This effectively increases 
software code reuse.
\item NetQoPE makes network provisioning decisions in coordination with 
component placement algorithms that consider host resources, specifically 
CPU. This capability we have demonstrated is a major practical step in 
quality of service research to take into account two main resources 
simultaneously. Allocation problems that take into account both CPU and 
network resources are l integer programming problems that are more 
intractable than bin-packing problem formulations for the CPU resource.
\end{itemize}

The Bandwidth Broker technology~\cite{Das:2005,Das:2006} incorporates 
mechanisms to dynamically adapt to network faults. When there is a 
fault, in essence, one or more admitted flows take new paths to 
circumvent the link or router that has failed. This, in turn, 
could overload some of the links causing QoS guarantees of some 
previously admitted flows to be missed. The Bandwidth Broker is 
capable of rediscovering paths as soon as the fault is detected and 
making re-admission decisions. The readmission decision can be policy-driven.
Policies such as ``drop as few flows as possible'', ``drop only low priority
flows'', etc can be supported in a plug-and-play manner.

However, an application may not be prepared to work with the 
degraded quality of service for the demoted flows regardless of 
the readmission policy chosen. One strategy is application-level 
adaptation that essentially involves substituting a different 
implementation for the same component during runtime~\cite{Schmidt:05p} 
for one or more components making up the application. 
This is because two different implementations for the 
same component may require different network QoS. Our future work 
will focus on developing selection algorithms~\cite{Yellin:03} that can automatically 
choose the most suitable component implementation to operate in the case 
of network resource scarcity. We will implement these selection algorithms 
and validate them in the context of a DRE application such as the office 
of the future environment discussed in this paper.
