A QoS Gateway Architecture in Enabling the First Mile forQoS-Dependent Applications and Appliances

Mohamed El Gendy and Kang G. ShinReal-Time Computing Laboratory

Department of Electrical Engineering and Computer ScienceThe University of MichiganAnn Arbor, MI 48109-2122�

mgendy,kgshin@eecs.umich.edu �April 8, 2005

Abstract

We present the design of a two-tier architecture, called a Quality-of-Service (QoS) Gateway, that (i) acts asan interface between application QoS requirements and network-provided QoS capabilities, and (ii) supportssmall embedded network devices that rely on network-provided QoS support. The QoS Gateway will promotewide QoS deployment and facilitate construction of QoS-aware access networks. It also provides QoS-basedprotection for Peer-to-Peer (P2P) services and applications located in customer networks through incoming traf-fic control and Adaptive Packet Filters (APFs). The QoS Gateway is composed of two key components: (1) anagent that resides close to end-hosts and provides an adequate interface for QoS-dependent applications, and(2) a QoS manager that provides an interface to network services for the agents. Using these two componentsenhances generality and scalability in providing QoS support for Internet applications and end-devices. Werealize the main functionality of the architecture as Linux-based software prototype, and we also plan to usenetwork processors available in the market to realize the performance-critical and complex functionality of theQoS Gateway and address the research issues associated with this implementation. The flexibility, programma-bility, and ability of network processors architecture to handle high-throughput data plane make them ideallysuitable for implementing efficient QoS gateways.

1 Introduction

1.1 Objective

The past few years have witnessed the convergence of digital technologies such as television, telephony, publish-ing, and computers. This convergence has prompted many QoS-dependent applications on the Internet [18], thatrequire certain service quality from the underlying network such as guaranteed throughput, reliability, timeliness,and packet delivery. For example, a wide variety of home devices and computing facilities, such as desktop PCs,Voice over IP (VoIP) phones, home telemetry and automation devices, home entertainment (mostly multimedia),shared data storage devices, as well as others, are getting connected via a Home Area Network (HAN) in what iscalled “smart homes” as will be described in Section 4. A HAN, as well as other examples of customer networks,are usually connected to the external network via cable modems, digital subscriber line (xDSL), ISDN, opticalfiber, IEEE 802.11 wireless and other standards. Due to the wide range and the dynamic operation of applicationsrunning on these devices, they require different network resources, and these requirements vary from local (withina HAN or customer network) to global (end-to-end, e2e) resources. Moreover, different physical media connectingthe customer network to the external network affect the overall performance of such applications. Maintaining a

1

satisfactory QoS level for applications with such varying network connectivity and complex application interac-tions poses a significant challenge that requires intelligent resource allocation and admission control as well asadequate QoS support to handle diverse link media and dynamic link quality associated with each medium.

On the other hand, with the introduction of new and different multi-service network technologies to the Internet,it becomes a tedious and oftentimes error-prone job to upgrade each application in order to accommodate the newtechnology. Moreover, managing service contracts with different network service providers and resource-usageaccounting increase complexity in customer network management and end-host devices. Therefore, an abstrac-tion layer is needed to provide an interface between the QoS-enabled network and QoS-dependent applications.This abstraction layer hides all the complexity of Service Level Agreement (SLA) management, QoS mapping,admission control, and even data-plane traffic handling such as packet marking and policing.

To address the above needs and, at the same time, to provide QoS accessibility and support to QoS-dependentapplications and devices, we present a two-tier architecture, called QoS Gateway [6], that acts as a QoS mediatorbetween these applications/devices and the underlying network QoS infrastructure. The QoS Gateway also actsas an abstraction layer that hides the complexity of the QoS-enabled network from QoS devices and applicationsas shown in Figure 1. This has the advantages of shielding the device or the end-host application from the detailsof the underlying QoS infrastructure and facilitating both QoS management and deployment. As will be detailedlater in this report, the QoS Gateway is composed of QoS Agents that are working as close as possible to QoSapplications and end-devices in the access network (tier 1), and QoS Managers that are working closer to anexternal provider network before the access router (tier 2). Part of the main functionality of the architecture havealready been implemented on a Linux-based software prototype in [6], which is summarized for completeness,and we will make a new important realization of the architecture using network processors available in the market.Wire-speed complex and context-based packet processing as well as flexibility and programmability needed by theQoS Gateway are the main reasons for using network processors to realize such a complex functionality in theaccess network.

Access networking equipment must support multiple interfaces and protocols. This equipment also needs tomeet tight power and real-estate requirements dictated by space constraints. The equipment deployed at the edgeof the network must support rapid provisioning of services, scalable performance to provide support for emergingservices at wire speed and smooth migration to emerging standards. Minimizing costs while maximizing time-in-market is also a critical concern.

1.2 Design Considerations

One important feature of our approach is its modularity in design, which can be easily reconfigured and upgradedwhenever there is a change in the working environment or the network support. This way, it acts as a virtual QoSstub that hides changes in the external network from the local network, hosts, and applications. In addition to theset of initial design considerations we mentioned in [6], we list here three more considerations.

� Heterogeneous interfaces: Different devices use different connectivity standards and links to connect to theexternal network. LAN, DSL, PPP, IEEE 802.11, USB, RS-232, Bluetooth, and infrared are a few examplesof these. It is necessary for the proposed architecture to (1) support multiple interfaces to different types ofhosts/applications and (2) enable adaptive communication with them.

� Multi-level of QoS mapping: QoS mapping is done at both the agents and the managers levels. Thisallows more freedom in meeting QoS-application requirements and provides a larger adaptivity margin toaccommodate transient and dynamic changes in the external network.

� Bidirectional QoS support: QoS enforcement on outgoing traffic as well as QoS regulation on incomingtraffic are necessary in today’s P2P customer networks as they contain both contents providers as well as con-tents clients at the same time. Our design meets this requirement by providing QoS support for application

2

computer

Different Hosts/ Applications

Laptop

Fax

PDA

Server DiffServ

IntServ

IEEE 802 QoS

QoS Gateway

Different QoS- Enabled Networks

1 2 3

4 5 6

7 8 9

* 8 #

IP phone

P R I N T

H E L P

A L P H A

S H I F T

E N T E R R U N

D G E R F I

A J B K C L

7 M 8 N 9 O

D G D G D G

D G T 3 U

0 V . W X Y Z

T A B

% U T I L I Z A T I O N

H U B / M A U N I C

2 B N C 4 M b / s

embedded

Figure 1: The QoS Gateway as an abstract inter-face to different networks

SLA

QoS-enabled Network

QoS Classes

End-Host

QoS Agent

QoS Applications

Other Applications

Operating System

Network Interface

Small & Embedded Devices

Customer Network

QoS Managers

End-Host

QoS Request

Stand-alone QoS Agent

Access Router

Customer Network

Customer Network

Customer Network

Tier 1 Tier 2

Figure 2: Basic architecture for the QoS Gateway

traffic going out of the supported customer network using different traffic tagging and mapping techniques.Using different traffic control techniques, it also provides QoS support for incoming traffic to servers withinthe customer network according to workload monitoring on these servers.

2 Architectural Design of the QoS Gateway

We now present the architectural design of the QoS Gateway and describe our realization that can fit on boththe software prototype and the hardware network processors. The switching in the QoS Manager can be done athigh-level layers such as layer 4 (Transport) or 7 (Application), so the need for high-speed, and at the same time,flexible multi-field packet processing is a driving force towards use of the network processors in realizing the QoSGateway architecture. Figure 2 depicts a general architecture of using QoS Agents and QoS Managers to establishservices for applications running on hosts as well as on small and embedded devices. We also discuss the researchissues associated with this QoS Gateway realization and list the milestones and deliverables of this project.

2.1 QoS Gateway Design

The key result of this project will be the detailed design and implementation of the architectural components of theQoS Gateway, namely, QoS Agent and QoS Manager. Our preliminary design and functionality of the host-basedQoS Agent has already been presented at IWQoS’04 as a software module, and was received exceptionally wellby both the academia (Zhili Zhang at Minnesota, Jorg Lieberher at UVa, and Hui Zhang at CMU), and industry(especially, Kerry Lynn at Cisco) attendees.

2.1.1 QoS Agent

The main functions of a QoS Agent is to capture the QoS requirements of applications and end-devices as well asother traffic characteristics, perform initial QoS mapping, and then communicate the application/device require-ments to the QoS Manager. It provides transparent QoS support for QoS applications and devices by interceptingtheir network connections and directing QoS requests to the QoS Manager so that it can assign suitable serviceclasses for applications traffic. The QoS Agent is designed as either a middleware that resides on the end-host oran external entity. The “host-based” middleware enables applications running on the host to access QoS in thenetwork and using such middleware design eliminates the need for modifying the host operating system. The other

3

Kernel Interface

Application QoS Mapping

Application Manager

Communication with

QoS Manager

QoS DB

Socket Layer QoS Module ( QoSmod )

Device File Interface User Space

Kernel Space

QoS Daemon (QoSd)

Network Interface

QoS Applications

w/o APIs

Other Applications

QoS Applications

w/ APIs

QoS API

Operating System

Request

Reply

Figure 3: Host-based QoS Agent main building blocks

realization, called “stand-alone” middleware, provides heterogeneous interfaces to a variety of QoS-dependent de-vices using IEEE 802.11, Bluetooth, USB, infrared, etc. The agent keeps track of registered devices, manages theirQoS, and monitors their traffic. Figure 3 shows the main building blocks of the host-based QoS Agent as well astheir interactions, while Figure 4 shows the stand-alone agent.

The QoS Agent creates a QoS profile for each application to be run on the host or each device to be connectedwith it. The QoS profiles are used to map applications’ and devices’ QoS requirements to their equivalent network-level QoS representations that are later used by the QoS Manager in assigning service classes. This two-level QoSmapping to the application requirements allows more flexibility in meeting application QoS requirements withavailable network services.

The host-based QoS Agent’s functionality is divided into two parts, a QoS module (QoSmod), which works inthe operating system’s kernel space,1 and a user-space daemon, which is called QoS daemon (QoSd). The daemonand the module communicate via a special channel or a device driver. The QoSmod intercepts applications’ networkconnections and contacts the daemon to perform QoS mapping, and admission control with the QoS Manager.The application has to be registered with the host agent in order to intercept its network connections. SpecificApplication Programming Interfaces (APIs) are used to register new applications’ QoS profiles in the host database.Before storing the profile in the database, the agent maps the application’s QoS requirements to an intermediateform that is composed of bandwidth, delay, jitter, and loss. These parameters are called “network-level QoS.” Thisis the first level of QoS mapping done on the application requirements.

Socket-Call Capturing Module QoSmod provides a transparent interface to registered QoS applications byintercepting their socket system calls. For each intercepted socket call, the module notifies the user-space daemon,QoSd, and delivers important information about the call to the daemon. This information includes the type ofthe call, the calling application name, the process identifier, network addresses, ports, and protocol type. Thisinformation is used by QoSd to locate the QoS profile of the application in the database and performs QoS mapping.The network addresses and ports as well as protocol type are sent within the QoS request to the QoS Manager tobe used in traffic classifiers built for this application traffic on the manager. The QoSmod blocks the application(similar to waiting for a device) until a reply comes back from the daemon [4]. Once a reply is received from thedaemon, the module decides whether to continue the connection normally (if the application’s QoS can be met) orto drop the connection (if the application’s QoS request is rejected). Then, the module unblocks the application

1A kernel module in our Linux implementation.

4

computer

QoS applications & devices

Laptop

Fax

PDA

1 2 3

4 5 6

7 8 9

* 8 #

IP phone

P R I N T

H E L P

A L P H A

S H I F T

E N T E R R U N

D G E R F I

A J B K C L

7 M 8 N 9 O

D G D G D G

D G T 3 U

0 V . W X Y Z

T A B

% U T I L I Z A T I O N

H U B / M A U N I C

2 B N C 4 M b / s

embedded Virtual device

interface Application QoS mapping

Application & Device Manager

Communication with

QoS Manager

QoS DB

External QoS Agent

Request

Reply

IEEE 802.11

USB

others.. � � � �� � � �Traffic monitoring

bluetooth /Infrared

� � � � � � �� � � � � � �IP stack / forwarding

Network interface

Control plane

Data plane

����� ��� � Applications &

devices traffic

Dev TAB

App TAB

Figure 4: Stand-alone QoS Agent main building blocks

with either normal or error code. Figure 5 shows how QoSmod processes a system call from a QoS application.In our Linux-based prototype, the module communicates with the user-space daemon through a special char-

acter device file called /dev/diff0. The module, when loaded, attaches itself to this device file, and providesread, write, poll, as well as perform other necessary functions to serve the file in the kernel space [17, 4]. Themodule also creates two message queues, a “send” queue (sndq) and a “receive” queue (recvq), for sending andreceiving messages to and from the QoSd, respectively.

The daemon, on the other side, listens to the device file waiting for any message sent from the kernel module.Messages sent to the daemon are either reporting a socket call, informing the daemon of a process state change, orreplying to a request from the daemon. A message reporting a socket call carries the user and the process identifiersof the calling process. It also carries the necessary information about the socket call like the protocol family (e.g.,AF INET), the type of the call (e.g., accept, connect, send), the protocol (e.g., TCP, UDP), and the sockaddrstructure that have the addresses and port numbers of the two ends of the socket call. A message reporting aprocess state change contains the process identifier, and the current status of the process. Finally, a reply messageto a daemon request contains the result of executing such a request.

Messages received from the daemon contain a message type, process identifier, size, and a command from theapplication manager. There are two types of commands, either terminating a certain process (or application) orreplying to a socket call message from the kernel module. Upon receiving a terminate command or a terminatereply, the kernel module terminates the process immediately. Figure 6 illustrates the kernel interface in both thedaemon and the kernel module and shows how they work together.

Application and Device Interface and Management: QoS Agent provides a simple control API, called Re-questQoS(), to specify device’s2 QoS requirements. The control supports three functions, addQoS, modQoS,and delQoS. The first function, addQoS, is used to create a new QoS profile for the device’s traffic and storeit in the QoS database. The profile contains information about the name of the device, its type, number of flowsgenerated by the device, traffic profiles of the flows, required QoS for each flow, user authentication information,

2Device and application are used interchangeably onwards.

5

block process notify daemon

reply unblock process

system calls table

socket system call

qos_socket_call

sys_socket_call

continue socket call

to/from daemon

Figure 5: QoSmod operation

Listen

Application Manager

read write

socket call

process state

reply

command

reply

sendq recvq

QoSmod

kernel Interface

kernel space

user space /dev/diff0

QoSd

Figure 6: Kernel interface

and a unique identifier. The device’s QoS requirements are mapped first to their equivalent network-level QoSbefore being stored in the QoS database. We refer to this procedure as “device registration.”

The Application and Device Manager keeps track of registered QoS devices’ traffic sent to the external network.When a device registered in the QoS database starts, the corresponding QoS profile is fetched and a QoS request isbuilt and sent to the QoS Manager. The QoS Manager is contacted to perform admission control, network serviceclass selection, appSLA installation, and traffic control. This procedure is called “device invocation.”

QoS Mapping: QoS applications may have their own definitions for QoS and one of the main functions ofQoS Agent is to translate these various definitions to a common QoS form to be sent to the QoS Manager andhence map it to a specific network service class. The QoS mapping module takes care of implementing differentmapping algorithms for this translation process. The module also keeps track of the QoS database stored on thehost, which records all QoS applications that can run on this host. Records in this database carry a common formfor applications QoS which is referred to as the “canonical” QoS. This canonical form specifies QoS requirementsfor bandwidth, delay, jitter and loss. Specifically, it consists of a committed information rate (CIR), a peak rate(PIR), mean delay, maximum delay, jitter, and loss. We believe that any application’s QoS can be mapped to thisfinite set of parameters using appropriate algorithms. The QoS database also carries information about the trafficcharacteristics of these applications as well as information about their users. The latter information enables theagent to treat the same application differently depending on the user. We use the term “QoS profile” to describean entry in the QoS database. A typical application’s QoS profile consists of the application name (as a uniqueidentifier), flow identifiers (addresses and port of the traffic), protocol, traffic profile, and canonical QoS object.

QoS requests sent from the QoS Agent to the QoS Manager contains a canonical QoS object specifying therequired application’s QoS after being mapped, and a traffic profile description of the application traffic flows. Thetraffic profile follows the Dual Leaky Bucket (DLB) traffic model and includes the average rate, peak rate, burstsize, average packet size, and maximum packet size of the flow. In addition to the QoS and the traffic profile, theagent sends traffic identifiers to the manager to be used in the traffic classifiers installed on the manager.

As an example of application QoS mapping, consider a video transmission application that wishes to transmitframes at a rate of 30 frames/sec. Each frame can be sent at two different resolutions, a high resolution of �������������� and a low resolution of ����� ������� , and the application can tolerate the loss of 10% of frames every ���consecutive frames.3 At the other end, frames have to be played back at a specific speed and according to a play-out timer. If a frame is late by ����� of a frame time, it is considered as lost, and is not played back. Consider also

3This depends on the codecs used to send frames.

6

that the video received is used to activate a control action based on its content, and this control action has to betaken within ���� msec.4 The algorithm for this type of applications is straightforward. The CIR is the ��� ��� (inbits/sec) for transmitting lower resolution frames, and the PIR is the rate for transmitting higher resolution frames.The delay would be equal to the control delay ( ���� msec). The e2e jitter equals ������������� � �� ���� ����� ��� and theloss rate would be a � ��� �� �������� � �� ������ ��� ��� ������� � �� ���

in bits/sec, where ����� � �� �is the ����� � �� ����

divided by the �� ��� . This shows an example of how to extract the canonical QoS form from the application’s QoSspecifications. However, the job is not always easy like this example, and it can be a very complex operationand may also involve the user’s perception, which is still an open issue. The full investigation of the mappingalgorithms and adaptive techniques thereof is one of the main research issues to be tackled in this project.

2.1.2 QoS Manager

The QoS Manager acts as a QoS server for the set of agents in a local customer network, and provides an interfacefor applications to access various network QoS facilities and service classes. They process applications’ anddevices’ QoS requests by allocating network resources and suitable service classes to “outgoing” applicationstraffic. The QoS Manager is also responsible for regulating “incoming” traffic and service requests to customernetwork hosts and devices. The manager uses Adaptive Packet Filters (APFs) for this purpose. An APF mergespacket-filtering and server-load monitoring into a novel load-sensitive packet filtering abstraction for overloadprotection and QoS differentiation for “incoming” application traffic.

As shown earlier in Figure 2, the QoS Manager serves two types of end-hosts: hosts running QoS Agents aswell as hosts and devices that are not equipped with QoS support (e.g., small embedded devices) and hence connectto external QoS Agents.

For flexibility and upgradability, the QoS Manager is composed of two planes, a control plane (called Gateway)and a data plane (called TC Agent). The Gateway is responsible for high-level QoS control functions such as SLAmanagement, QoS mapping, admission control, and network QoS signaling. These functions are independentof the underlying network environment and can work with various QoS network infrastructures. The TC Agent,which handles traffic marking, traffic classification, and traffic control, is network-specific and tailored to matchthe supported QoS network infrastructure such as DiffServ or MPLS. Figure 7 illustrates the main building blocksof the QoS Manager as well as their interactions. In what follows, we will give details of the functionality of eachof these building blocks.

SLA Management: The QoS Manager acts as an interface between the offered network service classes andthe application’s QoS requirements, and manages SLA with the network service provider. It maps applicationrequirements to appropriate network service classes in the SLA. The QoS Manager keeps track of two types ofSLAs, network SLA (netSLA) for each network service class, and per-flow SLA (appSLA) for each active QoSapplication as illustrated in Figure 9. Entries for netSLAs are stored in a database “SLA DB” as shown in Figure 7.On the other hand, each application flow is associated with an appSLA entry. As application flows are admitted,appSLAs are created for each flow and mapped to suitable netSLAs.

QoS Mapping and Admission Control: Typically, network service providers specify service classes in theirSLAs in terms of capacity (amount of bandwidth available), latency (delay), delay variation (jitter), supportedpacket/frame sizes, availability (percentage of time available), reliability (sometimes referred to as loss rate), andschedule of operations. The QoS Manager maps the QoS of the application (appSLA) to one of the availableservices in the SLA (netSLA) by matching the values of its QoS parameters to the service specifications. Then, QoSmapping and admission control are invoked to assign the device traffic to a network service class with matchingend-to-end (e2e) QoS. The manager admits the appSLA if there is enough available bandwidth in the corresponding

4Video sensors are examples of such a situation.

7

Configuration Interface and Control

Host Communication

QoS Monitoring

SLA Manager

Policy and Accounting

Admission Control

SLA DB

Flow Classifier and Security

Check Scheduling

Policing and Packet Marking

Control Plane

Data Plane

Traffic Control and Packet Handling at Netowrk Interface

TC Agent

Gateway Manual

Configuration

to QoS Agent

Traffic

Ho

st S

ide

QoS Mapping

Security and Authentication

Traffic

Figure 7: QoS Manager main blocks

Customer Network

Server

Access Router

Access Router

PATH

PATH

PATH

RESV RESV

RESV

Network Service Classes

E2E RSVP

Signaling

QoS Manager A

QoS Manager B

Figure 8: E2E QoS verification via RSVP

netSLA. For e2e QoS verification, we propose the use of RSVP, initiated from the QoS Manager, working inadmission control mode as specified in [3]. Figure 8 illustrates the process of e2e QoS verification.

Traffic Control and Marking: After admitting a flow, the Manager installs traffic classifiers and policies basedon the flow identifier and traffic profile in the flow’s appSLA, respectively. Packet markers, such as those in [7, 9],are installed for the traffic flows using the DSCP assigned to the flow from the corresponding netSLA.5 When theflow terminates, the Manager deletes the corresponding traffic controls and markers and frees their resources.

Customer Network Resource Access Control: An important function of the QoS Manager is to protect thecustomer network resources from theft and abuse. It implements the IP Easy-pass resource access control schemewe developed [19] for this purpose.

5Assuming the DiffServ network architecture.

8

Per class/aggregate QoS Per-flow QoS

Class A

Class B

Class C

netSLA appSLA

QoS Manager

Figure 9: Network SLA (netSLA) and applicationSLA (appSLA)

IEEE 802.1p QoS Interface

Gateway

RSVP Daemon

Control Plane

Data Plane

Kernel Traffic Control

User Space

Kernel Space

Qo

S M

ang

er

DiffServ Interface

SBM

Figure 10: Flexibility in QoS Manager design

Flexibility in QoS Manager Design: One of the QoS Gateway design considerations is flexibility to work withdifferent underlying network frameworks. Figure 10 shows this flexibility in separating the control plane from thedata plane in the QoS Manager. We can use multiple different data planes (e.g., DiffServ-specific, IntServ-specific,IEEE 802) that work with different underlying networks. However, the control plane remains unchanged. More-over, the e2e signaling module in the QoS Manager can be replaced by a compatible module that uses network-specific signaling protocols (e.g., RSVP, Subnet Bandwidth Manager (SBM)). If the Manager is connected tomultiple networks at the same time, then it can switch between different data planes.

2.2 Adaptive Packet Filtering of Incoming Traffic

The design described so far provides QoS management for applications’ and devices’ outgoing traffic. However,as Peer-to-Peer (P2P) network architectures are becoming widespread, it is common to install network servers in-side the customer network (such as HTTP, File or VoD servers). Hence, protecting these servers from “incoming”(possibly DoS attacks or flash crowds) traffic according to a predefined QoS profile is also required to provide fullQoS support to a customer network. By exploiting our previous work [11], we would like to integrate the function-ality of Adaptive Packet Filters (APFs) into the QoS Gateway so as to provide a bidirectional QoS managementarchitecture as illustrated in Figure 11.

An APF allows a set of filters to be loaded into a filter controller and accepts feedback from load monitors asillustrated in Figure 12. Depending on the configured filters and load indicators, an APF automatically enforces anappropriate filter that deals with server overload. APFs do not rely on any specific monitoring mechanism and canbe integrated with various sources of monitoring information, e.g., SNMP, Tivoli, etc. Network-based QoS controland differentiation requires basic packet classification where each packet, once classified, will be treated accordingto a policy associated with its traffic class. Traffic classes are defined by information contained in the packets’ IPheaders.

� Server-side applications via IP destination information.

� Client population via IP source address prefixes.

� Packet types, such as TCP, TCP-SYN, UDP, IPX, and ICMP.

� DiffServ code points.

� A combination of the above.

9

Incoming QoS Management

(APF)

Outgoing QoS Management

(Gateway/TC Agent)

QoS Manager

ISP

Net

wo

rk

Cu

sto

mer

Net

ow

rk

Figure 11: Bidirectional opera-tion of the QoS Gateway

Figure 12: APF operation Figure 13: FDim in APF

The APF notion of traffic classes is used in firewall configuration. A rule combines a traffic class and a policy.A policy specifies whether packets of a traffic class should be accepted, dropped, shaped, or policed to a particularrate. If multiple rules apply to an incoming packet, the most restrictive policy will be applied to the packet. Thisdefinition of rules is consistent with that of most modern firewall implementations. Each individual rule definesQoS requirements for exactly one traffic class. Thus, QoS differentiation between competing traffic classes canonly be achieved by installing rule combinations. Rule combinations are expressed in filters. For example, a filterof two rules could be set up to admit twice the packet rate of IP address Y for IP address X. To guarantee QoSdifferentiation, the rules of a filter are considered a unit, i.e., all or none of its rules are enforced. To make filtersapplicable to environments of unknown or variable server processing capacities, it is necessary to implement filteradaptation. Fixed filters with inadequate shaping rates could easily cause under-utilization of network servers.For example, if one restricts incoming traffic to a moderately-loaded Internet server, one risks dropping requestswhich the server could have handled easily. However, installing only loose filters to accommodate the common(lightly-loaded) case would lead to server overload and request drops. So, such filters will fail to defend the serverfrom load surges.

Filter adaptation is achieved in filtering dimensions (FDims). Each FDim is a linear list of filters, ����� ������������� �� ,only one of which is enforced at any given time. A switch from one filter to another is an atomic operation, meaningthat the old filter is uninstalled and the new filter is installed without processing any network packets in between.Figure 13 shows an expanded view of an FDim. The filter selection process is driven by an FDim-specific loadindex which is fed by the load-monitoring module within the host-based QoS Agent.

Multiple FDims may be installed simultaneously, each tied to its own load variable. This pays tribute to thefact that different types of overload may be caused by different network services, which must be policed separately.Support for multiple FDims is particularly useful when an APF-enabled device controls access to different services,each of which is located on its own separate backend server.

2.3 Open Technical Issues

Listed below are some of the open issues in our solution:

Adaptive application QoS mapping and resource allocation: Coping with today’s dynamic applications and stand-alone networking devices’ traffic, we will investigate adaptive techniques for mapping their traffic to avail-able network resources and service classes. This will enable efficient use of the available network servicesas well as optimizing the cost for using these services on the customer network. Finding a good match be-tween users’ subjective QoS measures and network objective QoS parameters is also an important issue ofapplication QoS mapping.

Dynamic resource collision resolution: When new applications or devices are installed on the customer network,a new set of QoS requests are generated and new traffic rules are to be installed. Doing this seamlessly

10

without interfering with already-running applications/devices is an important issue that we will investigatein our design.

Distributed and hierarchical QoS Gateway architectures: Some customer networks are multi-homed (connectedto multiple service providers), thus requiring more than one QoS Gateway. Similarly, when the size of thecustomer network is large (such as a large corporate network), the load on a single QoS Gateway can bevery high, we may need more than one gateway. The gateways can be arranged in a flat organization (eachwith an equal or weighted load), or in a hierarchical organization (multiple levels of functionality and trafficaggregation).

Dynamic pricing and accounting: Typical home and office applications and devices do not run continuously(operate according to a dynamic on/off schedule). Accounting and pricing have to reflect the actual resourceusage and QoS received by these applications and devices. Having a host agent that keeps track of thedynamic operation of each individual application and device in the network facilitates such tracking.

3 Related Work

Previous approaches depend on either putting all of these functionalities in the end-host operating system (suchas IBM AIX [13] and Windows 2000 [1]) or deploying hardware devices, called QoS appliances [16, 5, 15]. Theformer approach does not address the QoS needs of other architectures, like small-memory devices and embeddedsystems, and also creates heavy dependency on the end-host operating systems. This has the disadvantage ofrelying on the QoS support “canned” in the underlying operating system, hence yielding inflexible solutions andlimiting deployability. On the other hand, the latter approach provides only bandwidth management for differentapplications traffic. However, it does not provide enough flexibility to export network services up to the applicationlevel. Usually, some kind of mapping or translation is required between the application QoS requirements andavailable network services. The intelligence found in current QoS appliances is not sufficient enough to providesuch QoS mapping.

A similar architecture to the QoS Gateway was presented in [14], which is called the QoS Broker. The QoSBroker orchestrates resources at the end-points and coordinates resource management across layer boundaries.Their architecture is tailored to ATM and manages application, network, and system QoS parameters. The QoSBroker architecture shares some common features with the QoS Gateway, such as hiding network configurationand operational details from applications and higher layers, and the use of a module-structured design, but the maindifference is the use of two-tier architecture in the QoS Gateway. This has the advantages of easy upgrade, supportfor heterogeneity, resource aggregation, and security.

Two examples of QoS-enabled Residential Gateway (RG) are presented in [12, 2]. The first system mainly con-trols bandwidth allocation for different devices in a HAN. The authors classified home-generated traffic into sevencategories based on bandwidth requirements. The second system works on layer 2 (MAC) and layer 3 (network),and is compliant with existing standards such as IEEE LAN Subnet Bandwidth Manager (SBM), and RSVP. TheQoS Gateway architecture provides a more general architecture in terms of functionality and deployment environ-ment.

Providing QoS APIs through the socket layer has been presented in [8] and called QoSockets. The authorsintroduce an extension to the UNIX socket interface that support e2e application QoS management. Althoughthey share a similar goal with our architecture, the main disadvantage of their approach is the lack of transparentsupport. For the applications to take advantage of the new socket calls, they have to be reprogrammed to use theQoS APIs. Our architecture provides a transparent support for both types of applications, those that are not usingthe APIs and those that use the APIs.

In [10], a QoS Library Redirection (QLR) approach was presented on Microsoft Windows systems. Theauthors use a similar idea of intercepting socket calls from the Import Address Table (IAT) on Windows, and

11

redirect the calls to add packet marking to the traffic before starting. However, this work is considered a subsetof our architecture as no consideration for QoS mapping, SLA management, or admission control were presentedin QLR. The QoS Gateway architecture provides a complete integrated system, not just APIs, for providing QoSsupport to applications.

4 Potential Impact

A typical working environment for our proposed system is called “Cyber Apartment Complex” where buildingsand apartments in such a complex are connected to the QoS Internet through QoS management devices. Figure 14illustrates this environment where each cyber apartment has various devices (ranging from small embedded devicessuch as security cameras to full personal computing facilities such as desktop PCs). As mentioned in Section 1,applications running on these devices are usually QoS applications such as IP phones that use VoIP technology, oreven a real-time automatic control signal for household devices like ovens or lighting.

Switch

Backbone Switch

Access Router

Internet

Complex Segment A

Complex Segment B

Cyber Apartment Complex

QoS Managers

QoS Agents

Cyber Apartment

Cyber Apartment

Cyber Apartment

Cyber Apartment

Cyber Apartment

Switch

Switch

Figure 14: A typical deployment scenario

QoS Gateways have a better view of network resources and network service classes, and decide which applica-tion/device network traffic can receive which service level and which policy to apply to this particular traffic. QoSenforcement, bandwidth management, traffic policing and conditioning, traffic monitoring and accounting, policyenforcement, SLA, and admission control are among the functions that a typical QoS Gateway performs to provideQoS support for home devices and applications.

Of course, home networking is not the only environment that can make use of the QoS Gateway architecture.Any type of customer networks can use the architecture as a “stub” for accessing QoS features in the provider’snetwork that can handle all the issues of interfacing and accounting as well as other functionalities required forQoS enforcement.

The computing industry in general will benefit significantly from the our solution because it will help realizea rapidly growing number of QoS applications in residential and office environments. Since it focuses on issuesassociated with end-systems/devices and end-networks, its full benefits will be realized if networks are equippedwith some form of QoS support, such as DiffServ or MPLS.

12

References

[1] Windows 2000 Features in Support of Differentiated Services, July 2000. White paper,http://www.microsoft.com/TechNet/win2000/win2ksrv/diffserv.asp.

[2] D. Bansal, J.Q. Bao, and W.C. Lee. QoS-Enabled Residential Gateway Architecture. IEEE CommunicationsMagazine, April 2003.

[3] Y. Bernet et al. A Framework for Integrated Services Operation over DiffServ Networks. RFC 2998, IETF,November 2000.

[4] D.P. Bovet and M. Cesati. Understanding the Linux Kernel. O’Reilly, 2001.

[5] Allot Communications. Netenforcer. http://www.allot.com.

[6] M. El-Gendy, A. Bose, S.T. Park, and K.G. Shin. Paving the First Mile for QoS-dependent Applications andAppliances. In Proceedings of International Workshop on QoS, IWQoS’04, Montreal, Canada, June 2004.

[7] M. El-Gendy and K. G. Shin. Equation-Based Packet Marking for Assured Forwarding Services. In Pro-ceedings of IEEE INFOCOM’02, New York, June 2002.

[8] P.G.S. Florissi, Y. Yemini, and D. Florissi. QoS Sockets: a new extension to the sockets API for end-to-endapplication QoS management. Computer Networks, 35(1), January 2001.

[9] J. Heinanen and R. Guerin. A Two Rate Three Color Marker. RFC 2698, IETF, September 1999.

[10] W. Hwang et al. An Approach of QoS Library Redirection Method for DiffServ in Microsoft WindowsSystems. In Proceedings of IEEE GLOBECOM’01, San Antonio, TX, November 2001.

[11] J.Reumann, H. Jamjoom, and K.G. Shin. Adaptive Packet Filters. In Proceedings of the IEEE Globecom’01,San Antonio, TX, 2001.

[12] B. Lei, A.L. Ananda, and T.S. Teck. QoS-aware Residential Gateway. In Proceedings of the 27th AnnualIEEE Conference on Local Computer Networks (LCN’02), 2002.

[13] A. Mehra, D. Verma, and R. Tewari. Policy-Based DiffServ on Internet Servers: The AIX Approach. IEEEInternet Computing, September-October 2000.

[14] K. Nahrstedt and J.M. Smith. The QoS Broker. IEEE Multimedia Magazine, 2(1), Spring 1996.

[15] Sitara Networks. Qosworks. http://www.sitaranetworks.com.

[16] Packeteer. Packetshaper. http://www.packeteer.com.

[17] A. Rubini and J. Corbet. Linux Device Drivers. O’Reilly, 2001. 2nd ed.

[18] D. Verma. Supporting Service Level Agreements on IP Networks. Macmillan Technology Series, 1999.

[19] H. Wang, A. Bose, M. El-Gendy, and K.G. Shin. IP Easy-pass: Edge Resource Access Control. In Proceed-ings of IEEE INFOCOM’04, Hong Kong, March 2004.

13