QoSINUS

QoS INvocation and Usage System

[ Introduction | Use case example | Current implementation | Future works | Download | Documents | Contacts ]

Introduction

Nowadays, many routers used in high-performance core networks implement QoS fonctionalities. This is true, for example, in VTHD, which is the core network the e-Toile grid is build on. The routers of this high-performance network provide differentiated classes services (DiffServ) for that network's traffic. Four classes are available, respectively called EF, AF/TCP, AF/UDP, BE. The data packets are marked in one of those classes, and receive the forwarding treatment associated to that class at the routers.

Applications need that a certain level of QoS is ensured to the transmission of their data. But it might not be straightforward for them to translate their need into a DiffServ class. It would be nice instead, if they could specify such a level of QoS in a more abstract manner. For example, they could be given the option to specify a minimum bandwidth, a maximum loss and/or a maximum delay for their data streams. They might even be interested in defining their request using not only quantitative values but also qualitative values, like "high", "medium" or "low". Say, for example, that an application needs to transmit an audio stream. This kind of application is not that much concerned about loss of packets, requires a medium bandwidth, but has a strong need of low delay of transmission. It could then express it's QoS need as follow: "delay=low, rate=medium".

The programmable QoS system that we propose for is the glue between such an application high level QoS request and the backbone routers DiffServ forwarding treatment. The aim of the architecture is to map a high level QoS request into a DiffServ class, using monitoring informations. To provide that functionality, an active service is running on the router located at ingress of the DiffServ enabled backbone. It is responsible for monitoring the behavior of each DiffServ class in the core network, in terms of delay, loss and rate. Upon reception of a high level QoS request, it uses those monitoring pieces of information to determine the DiffServ class that matches the request the best. When the client's data stream is emitted, it's also up to this active service to mark the data packet in the chosen class, so that the corresponding DiffServ forwarding treatment is applied in the core network, and the requested QoS ensured.

The system described so far provides a mean to request a certain level of QoS and to actually provide that QoS to a transmission. On top of that mechanism, a policy has to be enforced, that defines how the QoS is negociated. The goal here is to control what QoS level might be granted to which stream. The e-Toile middleware includes a component, called the allocator, that takes care of job allocation on the Grid. That component is responsible for chosing the computing elements on which a job is going to be executed. As such, it is the piece of software that decides what is the destination of the grid's data streams. This allocator seems like a good candidate to enforce the QoS policy (ensure the network ressource allocation), just the same way he ensures the computing power allocation.

Use case examples in a Grid context

To help understand how the system works and might be used, here are four uses cases of QoSINUS showing how it could be integrated in a Grid environment.

  1. Use case 0

    In this first straighforward case, an application wants to control the DSCP that is used in its streams packets. QoSINUS includes a override mechanism that allows bypassing it completly to deal with that case.

  2. Use case 1

    Here, the sender of the data streams is responsible for specifying the QoS level for its streams to QoSINUS. That's the case of an application that sends data independly from the Grid middleware. That's also the case of Grid middleware specific data streams, like for example, the streams that flow when the Grid user interface requests the display of the Grid's useage statistics. The figure below shows this kind of use case.

  3. Use case 2

    The QoS might also be specified directly by the Grid's user. He might want, for example, to define the thruput to be assured to the transfer of the result data of his/her job. In this case, the QoS request is part of the job submission parameters (expressed in LDT, "langage d'expression des travaux"). The Grid's UI component is responsible for extracting this request, as shown below.

  4. Use case 3

    Finally, it might be up to the grid middleware itself to define the QoS to assure to the data streams circulating in the grid's network. Here the Grid's allocator, that is responsible for deciding where a job is going to be executed, sees the network as a ressource just like computing or storage elements. It takes its allocation decission taking into account a network transfer cost evaluation. Once the job is allocated, the Grid's middleware specify the QoS for the streams generated by the job's loading procedures, as shown below.

Current implementation

Architecture

QoSINUS is an active service that runs in the TAMANOIR active networking execution environment.

It consists in two part: a client API that is used by applications to request QoS to be ensured to their data stream, and an active service that runs on TAMANOIR active routers, deployed at the edge of the DiffServ domains.

Client API

The following functions are available for the client applications to use:

Active service

The QoSINUS active service might be broken into several components, as shown in the class diagram below. This service is running on the TAMANOIR active routers located at the DiffServ domain edges.

Mapping algorithm

Two mapping strategies have been implemented so far.

Download

Contacts