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


\section{Empirical Validation of NetQoPE}
\label{sec:results}

This section validates the network QoS provisioning capabilities
provided by the declarative mechanisms described in
Section~\ref{sec:solution}.

\subsection{Experimental Testbed and Setup}
\label{sec:setup}

The empirical validation of the NetQoPE framework was conducted at
the Vanderbilt's ISISLab (www.dre.vanderbilt.edu/ISISlab),
which is an open testbed for experimentation on distributed,
real-time and embedded systems. It consists of (1) 56 dual-CPU
blades (distributed over 4 blade centers each with 14 blades)
running 2.8 Gz XEONs with 1 GB memory, 40 GB disks, and 4 NICs per
blade, (2) 6 Cisco 3750G switches with 24 10/100/1000 MPS ports per
switch that can be provisioned using Network Simulator (NS) scripts
to emulate  different Layer-3 topologies and (3) Emulab (www.emulab.net)
software to reconfigure experiments via the Web using various versions
of Linux, *BSD UNIX and Windows.

All of our experiments were conducted on 16 of those dual CPU blades,
with 8 of them running as routers, and 8 of them running as the hosts
hosting the office environment scenario applications developed using
our QoS-enabled component middleware. All the machines were running
Fedora Core 4 Linux distribution, which supports kernel-level multi-tasking,
multi-threading, and symmetric multiprocessing.  All PCs were
connected over a 100 Mbps LAN and the standard linux router software was
used to configure the policing behavior. RACE is bundled as part of the
CIAO distribution, and CIAO version 0.5 was used as the component
middleware infrastructure. CoSMIC version 0.4.8 was used to model the
network QoS requirements of the office environment scenario applications.
The benchmarks ran in the POSIX real-time thread scheduling
class~\cite{Khanna:92} to enhance the consistency of our results by
ensuring the threads created during the experiment were not preempted
arbitrarily during their execution.

%\begin{floatingfigure}{0.6\columnwidth}
\begin{wrapfigure}{r}{0.5\columnwidth}
%\begin{figure}[htb]
  \centering
  \includegraphics[width=0.5\columnwidth,height=2.5in]{figs/experiments}
  \vspace{-0.1in}
  \caption{Experimental Setup}
  \label{fig:experiment}
%\end{figure}
\end{wrapfigure}
%\end{floatingfigure}

Our experiment set up is described in Figure~\ref{fig:experiment}.
{\em A, B, C, D, E, F, G,} and {\em H} are the hosts hosting the
software components developed using our QoS-enabled component middleware.
Software components include application software components, specifically
software controllers controlling the sensors, the software controllers
controlling the monitoring system, video servers and clients and surveillance
data generators. RACE and its integrated network resource Allocator
(which interfaces with Bandwidth Broker), developed using CIAO, is hosted on {\em C}.
The Bandwidth Broker runs on {\em C} as well. {\em P, Q, R, S, T, U, V}, and {\em W}
are the hosts hosting the router software, which is configured by the
Flow Provisioner also hosted on {\em C}.

Our office environment case study comprises of different classes of traffic,
as alluded to earlier in Section~\ref{sec:NetQoSMDE}:
\sqztiny
\begin{itemize}
  \item {\bf HIGH\_PRIORITY (HP)} -- this traffic class represents data
  flow from the smoke and fire detector sensors to the monitoring subsystem.
  The essential aspects of a fire or smoke incidence (e,g., location) need
  to be dispatched with utmost importance and quickly, i.e., low latency .
  The amount of data is typically small.
  \item {\bf HIGH\_RELIABILITY (HR)} -- this traffic class represents data
  flow from the surveillance cameras, which detect intruders. Since this is
  a stream of images, the bandwidth requirements are moderate. Moreover,
  since this image stream is used for security, this class of traffic requires
  high reliability, i.e., none to very little packet loss. The TCP protocol is
  used for this class. The latency requirement for this class is not that high
  as that of the HP class.
  \item {\bf MULTIMEDIA (MM)} -- his traffic class represents data flow 
  from applications, in the office environment scenario,that can tolerate 
  some packet losses, but require predictable delays and jitter. The 
  UDP protocol is used in this traffic class, and some common example 
  applications, most suited for this class, are video conferencing and 
  tickers propagating perishable information such as latest temperature 
  inside and outside a building.
\end{itemize}
There is one other class, {\bf BEST\_EFFORT (BE)}. This traffic class comprises
any other network traffic for which no QoS requirements are required.
We configured our network topology described in Section~\ref{sec:setup}
 with the following class capacities on all the links: 
{\bf HP} = 20 Mbps, {\bf HR} = 30 Mbps, and {\bf MM} = 30 Mbps for all the experiments. 
Moreover, the scheduling discipline used among these classes is 
strict priority; {\bf HP} has the highest priority and {\bf MM} has the 
lowest priority. The {\bf BE} class could use the remaining 
available bandwidth in the network.

Since all the network traffic is going to be sent by software components developed
using CORBA and Lightweight CCM, the core benchmarking software was
based on the single-threaded version of the ``{\tt TestNetQoPE}'' performance
test distributed with CIAO\footnote{``{\tt TAO/CIAO/performance-tests/NetQoPE}''
in the CIAO release contains the source code for this benchmarking suite}.
This performance test consists of two components, say A and B, and
creates a session for A  to communicate with B. The session is to permit a
configurable number of operation invocations by A on B with a configurable
sleep time between the invocations, and a configurable payload sent
for each invocation. This way, we could experiment
for different types of traffic by sending different types of payload, thereby
varying the bandwidth used for the communications.

We recapture briefly how the various tools in the tool 
chain are used to run the experiments:
\sqztiny
\begin{itemize}
  \item {\bf Modeling the QoS requirements} -- We used the modeling 
capabilities described in Section~\ref{sec:NetQoSMDE} to model the 
QoS requirements of the applications for which we were interested 
in observing the delivered QoS. The generative capabilities of 
the modeling tools synthesized the metadata comprising all the 
information on the components, and the QoS needs for the dataflows 
on the connections. The payload, and the number of iterations for 
each experiment are set as attributes on the CIAO component, so 
that they can be configured when the components are initialized. 
This allows the components to send the targeted network 
traffic for each experiment.
  \item {\bf RACE planning} -- The QoS requirements captured in the 
metadata generated by the modeling tools is used by the RACE planner 
to communicate with the Bandwidth Broker, which in turn determines 
the appropriate DSCP marking for that dataflow. The RACE planner 
updates this information into the deployment and configuration 
metadata it generates.
  \item {\bf CIAO network QoS policy and DAnCE frameworks} -- The 
DAnCE framework is responsible for deploying the components 
according to the metadata. The CIAO policy framework uses the QoS 
configuration information to mark the packet headers of outgoing 
communication flows with the DSCP markings captured in the metadata.
\end{itemize}

As to be expected, we used the TestNetQoPE software to generate traffic
among several pairs with different QoS (e.g., class, bandwidth amount,
transport)  at the same time. In the office environment case study,
for example, when the fire sensor senses a fire, and sends the location
of the fire to the monitoring subsystem, a video conferencing could be
happening. Therefore, the network could experience both {\bf HP} and {\bf MM}
traffic at the same time. These traffic flows also differ
in the amount of bandwidth they require and the transport protocol.

The overall goals of the experiments were:
\sqztiny
\begin{itemize}
\item Evaluating the effectiveness of the NetQoPE framework's 
traffic classes supported.
\item Evaluating the effectiveness of the NetQoPE framework's 
admission control mechanisms that ensures there is enough 
capacity for the flows that have been admitted and guaranteed QoS.
\item Evaluating the effectiveness of the NetQoPE framework's 
underlying network element mechanisms to police a flow for 
compliance, i.e., not to exceed its allocated bandwidth amount. 
\end{itemize}

\subsection{Experiments and Results}
\label{sec:experiments}

We now describe the  experiments  we performed using the lab 
setup described in Section~\ref{sec:setup}. Results and rationale for the 
results obtained are also given for each experiment

\subsubsection{Experiment 1: Effectiveness of the Traffic Classes Supported}
\label{sec:exp1}
\sqztiny
\paragraph{Rationale.} As we alluded to earlier, 
{\bf HIGH\_PRIORITY (HP)}, {\bf HIGH\_RELIABILITY (HR)}, 
and {\bf MULTIMEDIA (MM)} are the three classes being supported. 
In addition, there is a default class; the {\bf BEST\_EFFORT (BE)} class. 
The {\bf HP} class is the highest priority class for very critical traffic. 
{\bf HR} is for DRE applications that cannot tolerate packet loss where as the {\bf MM} class 
is for high volume DRE applications that can tolerate some 
loss, but require predictable delays. The {\bf HP, HR, MM} and {\bf BE} are 
supported by a Weighted Fair Queuing discipline with most 
scheduling slots for the {\bf MM} traffic and the least scheduling 
slots for the {\bf BE} class.  The {\bf HR} class has also a very large queue 
to minimize packet drops in our configuration.

These four traffic classes currently supported judiciously mix 
importance, latency, jitter and reliability QoS dimensions.
In other words, 
there is a dimension  reductionality. Although DiffServ allows 128 
different DCSP  markings or classes, generally the more the classes, 
the more the resource consumption and the slower  the forwarding 
behavior . Moreover, in Layer-2 networks (using CoS), there can only be 
at most eight classes.   So, we chose as few classes as needed but still 
satisfying the needs of our domain, the office environment, 
as we will demonstrate now.

This experiment was run with two variants: one when the 
applications were communicating using the TCP transport protocol, 
and another when the applications were communicating using the 
UDP tranport protocol. In all the experiments, We used 
high-resolution timer probes to measure the average roundtrip 
latency or one-way latency.

\sqztiny
\paragraph{Methodology for the TCP experiment.} ``{\tt TestNetQoPE}'' was
configured to make synchronous CORBA invocations with a payload
of 200000 bytes for 1000 iterations. 
The experiments were repeated when the network QoS requested was configured
to be one of: {\bf HP}, {\bf HR}, {\bf MM}, and {\bf BE}.
In each of the cases corresponding to these 
classes, 20 Mbps of network bandwidth was requested for the flow 
supporting the invocations in that class to the Bandwidth Broker. 
To evaluate application performance in the presence of background 
network loads, few other applications were run:

\begin{table}[h]
	\centering
		\begin{tabular}[c]{|l|l|l|l|l|}
			\hline Background Traffic & BE (Mbps) & HP (Mbps) & HR (Mbps) & MM (Mbps) \\
			\hline
			\hline
				Best Effort Application & 85 to 100 & & &   \\
		  \hline
		    High Priority Application & 30 to 40  &  & 28 to 33 & 28 to 33 \\
		  \hline
		    High Reliability Application & 30 to 40 & 12 to 20  & 14 to 15 & 30 to 31 \\
		  \hline
		    Multimedia Application & 30 to 40 & 12 to 20 & 14 to 15 & 30 to 31 \\
		  \hline
		\end{tabular}
	\caption{Background traffic in the TCP experiment }
	\label{tab:bgtrafficex1}
\end{table}

\iffalse
\begin {itemize}
\sqztiny
\item {\bf BE} application communications, with
the following background application communications:
85-100 Mbps {\bf BE}
\item {\bf HP} application communications, with the
following background application communications:
30-40 Mbps {\bf BE}, 28-33 Mbps {\bf HR},
and 28-33 Mbps {\bf MM}.
\item {\bf HR} application communications, with
the following background application communications:
30-40 Mbps {\bf BE}, 12-20 Mbps {\bf HP},
14-15 Mbps {\bf HR}, and 30-31 Mbps {\bf MM}.
\item {\bf MM} application communications, with
the following background application communications:
30-40 Mbps {\bf BE}, 12-20 Mbps {\bf HP},
14-15 Mbps {\bf MM}, and 30-31 Mbps {\bf HR}.
\end {itemize}
\fi

Please note that the background network traffic generated for our experiments
are not normally prevalent in everyday DRE systems, and they are more of
a worst case scenario. But we wanted to evaluate the performance of the
NetQoPE framework while operating in such worst case scenarios, and hence
generated such background loads.

\sqztiny
\paragraph{Analysis of results.} Figure~\ref{fig:results-tcp-latency}
shows the results of the experiments when the deployed CORBA applications communicated
using the TCP transport protocol. The results clearly show that, the average latency
experienced by the CORBA application using the {\bf HP} network
QoS class in presence of varied background network QoS traffic, is
much lower than the average latency experienced by the CORBA
application using the {\bf BE} network QoS class
in the presence of background applications generating
{\bf BE} network QoS class traffic. This shows that the NetQoPE 
framework can ensure an upper bound on 
latencies experienced by CORBA applications even in the presence 
of applications generating contending network traffc, thereby ensuring 
a performance much better than the performance in a non-QoS network. 
This should not be surprising, as the {\bf HP} traffic 
gets priority treatment over contending traffic from all other 
classes and as the {\bf HP} traffic limit is 
well within the link capacity.

The results also shows that the average latency experienced by CORBA application
using the {\bf HR} network QoS class, in the presence of a varied background
network QoS traffic is much lesser than the average latency experienced by
CORBA application using the {\bf MM} network QoS class, in the presence of a varied
background network QoS traffic. This is because of the different per-hop
behavior mechanisms configured for the different network QoS classes.
The size of the queues at the routers for the {\bf HR}
network QoS class is higher than the size of the queues at the routers for the
{\bf MM} network QoS class. 
%\begin{floatingfigure}{0.6\columnwidth}
\begin{wrapfigure}{r}{0.6\columnwidth}
%\begin{figure}[htb]
  \centering
  \includegraphics[width=0.6\columnwidth,height=2.5in]{figs/exp2_tcp}
    \vspace{-0.1in}
  \caption{Average Latency under Different Network QoS Classes}
  \label{fig:results-tcp-latency}
%\end{figure}
\end{wrapfigure}
%\end{floatingfigure}
This means that, in the event of network
congestion as generated in our experiments, the queues for the {\bf MM}
network QoS class are more likely to drop packets. This causes the TCP protocol 
flow control to reduce its window size by half, thereby causing application 
to experience more network delays while making the CORBA invocations. As more
network delays add up, the average latencies experienced by the CORBA application
increase, as illustrated for the {\bf MM} network QoS class in our
experiments.

This clearly shows that {\bf HR} network QoS class is more 
suited for CORBA applications communicating using the TCP 
transport protocol. Of course, the {\bf HP} 
network QoS class gives the best performance, but 
not every application can use HP, as its bandwidth 
capacity is relatively small and as it is it is for 
extremely critical, but low volume traffic.
In such cases, 
the applications should prefer using the {\bf HR} network QoS class.

\sqztiny
\paragraph{Methodology for the UDP experiment.} ``{\tt TestNetQoPE}''
was configured to make {\em oneway} CORBA invocations with a
payload of 500 bytes for 100000 iterations. We used high resolution
timer probes to measure the network delay for each CORBA invocation
on the receiver side of the communication. When the sender makes
an invocation, along with its invocation arguments, it also
sends a timestamp, which is the local time the invocation was made.
When the receiver receives the invocation, it records the difference
between its local time stamp and the time stamp that was sent
in the invocation. An offset between the sender and the receiver clocks
is accounted, and the adjusted difference is recorded as the network delay for the
invocation received by the receiver. We also kept count of the number
of invocations received by the receiver, to keep track of the losses
since the tranport protocol used is UDP. The experiments were
repeated using different network QoS classes, in the presence of different
background network traffic, as described below:

\begin{table}[h]
	\centering
		\begin{tabular}[c]{|l|l|l|l|l|}
			\hline Background Traffic & BE (Mbps) & HP (Mbps) & HR (Mbps) & MM (Mbps) \\
			\hline
			\hline
				Best Effort Application & 60 to 80 & & &   \\
		  \hline
		    High Priority Application & 30 to 40  &  & 27 to 28 & 27 to 28 \\
		  \hline
		    High Reliability Application & 30 to 40 & 1 to 9  &  & 27 to 28 \\
		  \hline
		    Multimedia Application & 30 to 40 & 1 to 9 & 27 to 28 &  \\
		  \hline
		\end{tabular}
	\caption{Background traffic in the UDP experiment}
	\label{tab:bgtrafficex2}
\end{table}

\iffalse
\sqztiny
\begin {itemize}
\item {\bf BE} application communications, with
the following background application communications:
60-80 Mbps {\bf BE}
\item {\bf HP} application communications, with the
following background application communications:
30-40 Mbps {\bf BE}, 27-28 Mbps {\bf HR},
and 27-28 Mbps {\bf MM}.
\item {\bf HR} application communications, with
the following background application communications:
30-40 Mbps {\bf BE}, 1-9 Mbps {\bf HP},
and 27-28 Mbps {\bf MM}.
\item {\bf MM} application communications, with
the following background application communications:
30-40 Mbps {\bf BE}, 1-9 Mbps {\bf HP},
and 27-28 Mbps {\bf HR}.
\end {itemize}
\fi

At the end of the experiments, for each network QoS class, at most 
100000 network delay values (in milliseconds) were recorded, 
if there are no invocation losses. Then those values are arranged 
in the increasing order, and every value was subtracted from the 
minimum value in the whole sample, i.e., they were normalized with 
respect to the respective class minimum latency. The samples were divided 
into fourteen buckets based on their resultant values. For example, the 
1 millisecond bucket contained only samples that are less than or equal 
to 1 millisecond in their resultant value. The 2 millisecond bucket contained 
only samples whose resultant values were less than or equal to 2 
millisecond but greater than 1 millisecond and so on.
\iffalse
the 3 millisecond 
bucket contained only samples whose resultant values were less than 
or equal to 3 millisecond but greater than 2 millisecond. 
\fi
Figure~\ref{fig:results-udp-jitter} deals mainly with the cardinality of each bucket.

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.8\columnwidth,height=2.5in]{figs/exp2_udp}
    \vspace{-0.1in}
  \caption{Network Delay Distribution under Different Network QoS Classes}
  \label{fig:results-udp-jitter}
\end{figure}

\sqztiny
\paragraph{Analysis of results.} Figure~\ref{fig:results-udp-jitter} shows the
network delay groupings for different network QoS classes under
different millisecond buckets. The results clearly show that
in the case of CORBA application configured to use {\bf MM}
network QoS class, about 94 percent of the invocations had their 
normalized network delays within 1 millisecond. This performance is:
\sqztiny
\begin{itemize}
\item Better than the network delay groupings recorded for application
configured to use {\bf BE} and {\bf HR}
network QoS class, where the values are spread over several buckets, indicating
varied network delays.
\item Comparable to the network delay groupings recorded for application
configured to use {\bf BE} network QoS class
in the presence of no background application network QoS traffic.
\end{itemize}

The latency performance of the application configured to use the 
{\bf MM} class is better than the latency performance of the 
application configured to use the {\bf HR} class because of the 
queue sizes configured for these classes. Since the queue size at the 
routers is smaller for the MM class in comparison to the queue size for 
the {\bf HR} class, the UDP packets sent as part of the 
CORBA invocations do not experience as much queuing delays in 
the core routers as the packets belonging to the {\bf HR} class. However, the 
{\bf MM} class traffic experienced more packet losses, which in turn means 
fewer invocations. This behavior of less latency at the cost 
of packet drops may be acceptable even ideal in some situations. For 
example, in the modern office environment {\em oneway} CORBA calls for 
sending temperature updates or even company stock updates tickers may 
prefer to use this {\bf MM} class.  For such applications, 
losing a few readings over a period does not matter as long as the 
most recent updates reaches the destination in time. 

\subsubsection{Experiment 2: Evaluating NetQoPE Framework's Admission Control Capabilities}
\label{sec:exp2}
\sqztiny
\paragraph{Rationale.} In Section~\ref{sec:resource_reserve}, we argued 
for the admission control capability for DRE systems over and 
beyond the two DiffServ features to guarantee QoS: 
(1) per-flow classification, marking and policing at the ingress, 
and (2) per-class differentiated treatment in packet forwarding 
at each of the routers. In this experiment, we demonstrate the 
need for admission control unequivocally.

\sqztiny
\paragraph{Methodology.} ``{\tt TestNetQoPE}'' was configured 
to make synchronous CORBA invocations using the 
TCP transport protocol with a payload of 20000 bytes for 
10000 iterations using the {\bf HR} class. We repeated 
the experiments with the following pairs of client-server 
communications between a pair of hosts: 1, 2, 3, 4, 5, 10, 15 
and 20. The experiments had the same background application 
traffic as described in the UDP experiment in Section~\ref{sec:exp1}. 
We used the admission control capability of the Bandwidth Broker 
for 1, 2, 3 and 4 pairs of client-server communication. 
In each of these cases, we allocated 6 Mbps for each pair of 
communication. The allocated capacity for the {\bf HR} class on 
each link is 30 Mbps.  So, the admission control permitted 
all the requests including the 4 pair case. For cases 
5, 10, 15 and 20 communicating pairs, we did not use the 
admission control capability. If the admission control capability 
were to be turned on, the Bandwidth Broker would not have admitted 
more than 5 pairs of communications or flows.  Hence, we 
experimented 5, 10, 15, and 20 pairs of communication without 
this capability. The background application traffic in each of the 
network QoS classes was kept sufficiently high, so that these 
{\bf HR} flows did not get bandwidth from other traffic classes.

\begin{figure}[htbp]
\sidebyside {
  \centerline{\includegraphics[width=7cm, height=2in]{figs/admission_control_new}}
  \bfcaption{Average Invocation Latencies with Admission Control} \label{fig:results-admission-control-new}} {
  \centerline{\includegraphics[width=7cm, height=2in]{figs/admission_control_tcp}}
  \bfcaption{Average Invocation Latencies without Admission Control} 
  \label{fig:results-admission-control-tcp}}
\end{figure}

% %\begin{floatingfigure}{0.6\columnwidth}
% \begin{wrapfigure}{r}{0.6\columnwidth}
% %\begin{figure}[htb]
%   \centering
%   \includegraphics[width=0.6\columnwidth]{figs/admission_control_tcp}
%     \vspace{-0.1in}
%   \caption{Average Latencies for Different Number of Clients}
%   \label{fig:results-admission-control-tcp}
% %\end{figure}
% \end{wrapfigure}
% %\end{floatingfigure}
% 
% %\begin{floatingfigure}{0.6\columnwidth}
% \begin{wrapfigure}{r}{0.6\columnwidth}
% %\begin{figure}[htb]
%   \centering
%   \includegraphics[width=0.6\columnwidth]{figs/admission_control_new}
%     \vspace{-0.1in}
%   \caption{Average Latencies for Different Number of Clients}
%   \label{fig:results-admission-control-new}
% %\end{figure}
% \end{wrapfigure}
% %\end{floatingfigure}

\sqztiny
\paragraph{Analysis of results.} Figure~\ref{fig:results-admission-control-new}
and Figure~\ref{fig:results-admission-control-tcp} 
show the average roundtrip latencies experienced by different 
numbers of clients, with and without admission control of the 
Bandwidth Broker, respectively. When the experiments were run with 
admission control, all the clients experienced the same average 
latency, as Figure~\ref{fig:results-admission-control-tcp} illustrates. 
This is because all the clients were allocated 6 Mbps of network bandwidth, 
and the applications were able to get that bandwidth. When the 
experiment was run without admission control, all the deployed 
applications were to share the 30 Mbps of {\bf HR} class bandwidth. 
When 5 communicating pairs were deployed, the available bandwidth was 
close to 6 Mbps for each of the application, and hence the latency 
experienced by the clients was almost equal to the latency experienced 
by the clients using the admission control capability. But as the number 
of client-server pairs increased to 10, 15 and 20, each communication 
pair bandwidth share started decreasing, causing the pairs to experience 
higher and higher latencies,  as illustrated in 
Figure~\ref{fig:results-admission-control-tcp}. 

This demonstrates the need for DRE system middleware to incorporate 
admission control so as to ensure predictable performance for 
the application component communication and hence end-to-end 
application performance. 

\subsubsection{Experiment 3: Evaluating NetQoPE Framework's Traffic Policing Capabilities}
\label{sec:exp3}

%\begin{floatingfigure}{0.6\columnwidth}
\begin{wrapfigure}{r}{0.6\columnwidth}
%\begin{figure}[htb]
  \centering
  \includegraphics[width=0.6\columnwidth,height=2.5in]{figs/exp4_tcp_hp}
    \vspace{-0.1in}
  \caption{Effect on Invocation Latency due to Policing}
  \label{fig:results-tcp-policing}
%\end{figure}
\end{wrapfigure}
%\end{floatingfigure}

\sqztiny
\paragraph{Rationale.} A key basis of our network QoS guarantees 
is that an admitted flow will not routinely exceed its 
allocated bandwidth. If a flow were to consistently violate 
its usage of the network resource, one or more flows that share 
a link with the flow may not be able to get its/their share of the 
bandwidth. So, policing for compliance at the granularity of a flow 
at the ingress router is required, and modern routers and switches 
support this feature.  In this experiment, we validate this policing 
feature and demonstrate its usefulness.

\sqztiny
\paragraph{Methodology.} ``{\tt TestNetQoPE}'' was configured 
to make synchronous CORBA invocations using the TCP 
transport protocol with a payload of 20000 bytes for 
10000 iterations using the {\bf HR} class. We repeated 
the experiments with the following  bandwidth reservation 
requests for the flow carrying the CORBA invocations: 20 Mbps, 
16 Mbps, 12 Mbps, 8 Mbps, and 4 Mbps. The experiments 
ran with the same background application network traffic as 
described in the UDP experiment from Section~\ref{sec:exp1}.

\sqztiny
\paragraph{Analysis of results.} Figure~\ref{fig:results-tcp-policing} 
shows the average latency experienced by the clients for the different 
bandwidth requests. The results show that the average latency 
linearly increases as the requested/reserved bandwidth amount 
decreases. (The ingress router for the flow was provisioned to 
police at the requested bandwidth rate.) Since the experiments 
were run to generate the same network load regardless of the 
bandwidth reserved, the lower the reserved amount, the sooner 
or more certain that the policing functionality kicks in 
dropping packets of the flow. When packets loss is detected, 
the TCP protocol at the sending end halves the transmission window 
size, thereby causing application to experience more network delay 
than before (the window size was halved) while making the CORBA 
invocations , i.e., lower the bandwidth size is, the higher the 
delay. It is to be stressed that the policing feature is independent 
of the protocol used, although each protocol may adjust differently 
when a packet loss is detected, i.e., when the policing function 
kicks in.

These experiments clearly show that applications configured 
with a specific network bandwidth reservation does not exceed 
this limit, thanks to the policing feature. This feature combined 
with the framework's admission control capability ensures QoS 
for all the admitted flows. 
