Throughput Guarantees for TCP Flows in
a Network Based on Packet Classes Using
Edge-to-Edge Per Flow Measurements
Lluís Fàbrega Teodor Jové Pere Vilà José Marzo
Institute of Informatics and Applications (IIiA) University of Girona
Campus Montilivi 17071 Girona, Spain
TCP flows generated by applications such as the Web or FTP require a minimum network throughput and can also benefit from an extra throughput due to their rate-adaptive algorithms. To build a guar-anteed minimum throughput service, the authors propose a scheme with Admission Control (AC) using a small set of packet classes in a core-stateless network. At the ingress of the network, each flow packet is marked as one of the set of classes, and within the network, each class is assigned a different discarding priority. The AC method is based on edge-to-edge per flow measurements and requires flows to be sent at a minimum rate. The scheme is able to provide different minimum throughput to different users and protection against nonresponsive sources. The authors evaluate the scheme through simulation using different traffic loads consisting of TCP flows that carry files of varying sizes. In the simulation, TCP uses a new algorithm that forces the source to keep the short-term sending rate above a desired minimum rate. The authors study the influence of several parameters on the performance of the scheme in different network topologies. The results show that the scheme guarantees the requested throughput to accepted flows and achieves a high utilization of network resources, similar to the ideal results of a classical hop-by-hop AC.
Keywords: Quality of service, TCP, guaranteed throughput service, admission control, elastic traffic
1. Introduction
Internet traffic is currently dominated by TCP connections carrying files generated by applications such as the Web, FTP, or peer-to-peer file sharing [1]. The users of these ap-plications expect no errors in the file transfer and the best possible response time. The source breaks up the file and sends a flow of packets at a certain sending rate, which the network delivers to the destination with variable delays and some losses. Losses are detected and recovered by TCP through retransmission, which adds more delay (increasing the transfer time) and may also cause packet duplication (discarded by the destination). From the point of view of
SIMULATION, Vol. 82, Issue 6, June 2006 383-397
© 2006 The Society for Modeling and Simulation International DOI: 10.1177/0037549706070265
the network, the decisive quality-of-service (QoS) param-eter is the average receiving rate or network throughput (including the duplicates).
A basic feature of TCP flows is their elastic nature. Sources vary the sending rate (up to the capacity of the net-work input link) to match the maximum available through-put in the network path. Since the available throughthrough-put changes over time, TCP uses rate-adaptive algorithms that increase and decrease the sending rate to match these vari-ations and minimize packet loss. TCP increases the send-ing rate if packets are correctly delivered and decreases it if packets are lost [2]. Another important feature of TCP flows is the heavy tail behavior of the file size distribution observed in traffic measurements [1]; that is, most elastic flows carry short files, and few flows carry very large files. Although the traditional view is that elastic flows do not require a minimum throughput, unsatisfied users or
high-layer protocols impose a limit on the file transfer time, and if it is exceeded, the transaction is aborted. This situa-tion implies a waste of resources, which can become even worse if the file transfer is tried again [3]. Moreover in a commercial Internet, the users will pay extra for the perfor-mance they require. Hence, there is a minimum throughput required or desired by users.
Elastic flows would be satisfactorily supported by a guaranteed minimum throughput service, providing a min-imum throughput and, if possible, an extra throughput. The service has an input traffic profile, based on sending traffic parameters (average rate, burst size, etc.), which defines the desired minimum throughput. If the average sending rate is within the profile, packets have a guaranteed (mini-mum) delivery; otherwise, packets have a possible (extra) delivery only when there are available resources, which are shared among flows according to a policy (best effort, priority to short flows, etc.).
The delivery of services between the provider and the user (an end user or a neighboring domain) is defined in a bilateral agreement (service-level agreements or SLAs). Regarding our service, the technical part of this agreement (the service-level specification or SLS) specifies that the user can request the service for each flow of an aggregation of any number of flows to any destination and also for any flow’s minimum throughput, as long as a contracted value is not exceeded. It also specifies the minimum percentage of requests the provider should satisfy (which is usually expected to be high).
We propose a scheme for a guaranteed minimum throughput service using Admission Control (AC) with simple and scalable mechanisms. The scheme does not need per flow processing in the network core since it only uses a small set of packet classes. At the network ingress, each flow packet is marked as one of the classes, and within the network, each class is assigned a different discarding priority. The AC method is based on edge-to-edge per flow throughput measurements using the first packets of the flow, and it requires flows to be sent at a minimum rate. In this article, we develop this scheme, initially outlined in Fàbrega, Jové, and Donoso [4], and we present simulation results using statistical traffic variations to show its validity as well as to study the influence of several parameters on its performance.
This article is organized as follows. In section 2, we re-view related work; in section 3, we describe our scheme, including the AC method; and in section 4, we present sim-ulation results using TCP flows in several network topolo-gies. Finally, we summarize the article in section 5. 2. Related Work on Throughput Services
The traditional network service on the Internet is the simple and robust best- effort service. Together with TCP rate-adaptive algorithms [2], this service has the goal of providing a fair throughput service. This means that it pro-vides a throughput equal to the sending rate when none of
the links of the path are overloaded, and when overloading does occur, it shares the bottleneck link’s bandwidth among the contending flows equally. A consequence is that if the number of flows in the bottleneck passes a certain limit, then none of the flows receive the desired throughput. In conclusion, during a congestion situation (when users’ de-mands exceed network resources), this scheme cannot pro-vide a desired minimum throughput to any flow. Moreover, it cannot provide a different throughput to different users, and TCP sources are not protected against nonresponsive sources (and therefore receive smaller throughput).
The Assured Service [5] is a proportional throughput service able to provide different throughputs to different users and protection against nonresponsive sources. It was defined in the Differentiated Services (Diffserv) architec-ture [6], which keeps the per flow state at the edge but not in the core, making the network more simple and scal-able. At the edge of a Diffserv network, each flow packet is assigned to a class, and a mark that identifies the class is written on the packet’s header (the number of classes is small). Having classified each packet into a class, the routers then apply a different treatment to each class. The Assured Service uses two packet classes (“in” or “out”), which are assigned at the ingress to each flow packet by comparing the actual sending rate to the desired minimum throughput. If packets have to be discarded in queues, the “out” class has a higher discarding priority than the “in” class. The Assured Service provides the desired minimum throughput when the aggregated “in” traffic does not cause an overload in any of the links of the path. When an over-load does occur, the provided throughput to each flow is a share of the bottleneck link’s bandwidth that is propor-tional to (and smaller than) the desired one. Therefore, the difference between the provided throughputs in congestion comes from the different desired throughputs of the flows. In congestion, like the best-effort service, the Assured Ser-vice cannot provide a desired minimum throughput to any flow.
Congestion could be avoided using resource overprovi-sioning or, in other words, dimenoverprovi-sioning network resources so that they are never exceeded by users’ demands. How-ever, this is a highly wasteful solution. If more efficient provisioning is used, congestion can be dealt with by AC. Instead of sharing the resources among all flows and hav-ing none of them receive the desired service, AC allocates the resources to certain flows, and only those flows receive the desired service. The goal of AC is to provide a desired minimum throughput to the maximum possible number of flows during congestion. Therefore, AC is actually better at satisfying more service requests, although it does make the network more complex.
A classical distributed AC method with hop-by-hop de-cision, based on per flow state and signaling in the core routers, is not appropriate for elastic traffic because of the low scalability (the number of flows can be very high) and the high overhead of explicit signaling messages (most flows have a short lifetime). As a result, other kinds of AC
methods have been proposed [7-9]. They have in common that they avoid the use of per flow signaling, maintain per flow state only at the edge or do not need it, and are based on measurements.
In the schemes proposed in Mortier et al. [7] and Kumar et al. [8], the provided throughput is the same for all ac-cepted flows, where a flow is defined as a TCP connection. A single link (or a logical path with a long-term resource reservation) is considered, and its current load is estimated from measurements of the queue occupancy. If the current load exceeds a certain threshold, new TCP connections are rejected by dropping the connection request packets or by sending reset connection packets. Therefore, the scheme does not require the per connection state.
In the scheme proposed in Ben Fredj, Oueslait-Boulahia, and Roberts [9], the provided throughput is the same for all accepted flows, where a flow is defined as a sequence of related packets (from a single file transfer) within a TCP connection. A network path is considered, and two measurement methods are proposed to estimate the available throughput: one measures the throughput of a phantom TCP flow, and the other measures the current loss rate of the path to convert it into a throughput esti-mate. Per flow state is only maintained at the edge, in a list of active flows updated implicitly: the start of a flow is detected when the first packet is received, and its end is detected when no packet is received within some defined timeout interval.
3. The Proposed Scheme
Our scheme is similar to Ben Fredj, Oueslait-Boulahia, and Roberts [9] in that a flow is defined as a sequence of related packets (from a single file transfer) within a TCP connec-tion, a network path is considered, and per flow state is only maintained at the edge. However, our scheme is able to provide different throughput to different flows as well as protection against nonresponsive sources. Moreover, it also uses measurements, but it is built from the Assured Service scheme [5] and the set of AC methods that uses end-to-end per flow measurements [10, 11]. Our purpose is to add AC to the Assured Service scheme also using a small set of packet classes. The scheme makes the follow-ing assumptions:
• We consider a multidomain scenario, where each domain has a user-provider agreement (SLAs) with each of its neighboring domains, and our scheme is used in one of the domains.
• A flow is a sequence of related packets (from a single file transfer) within a TCP connection (not a com-plete TCP connection, which usually has periods of inactivity).
• A list of active flows is maintained at the edge using an implicit mechanism to detect the start and end
of flows [9] (the use of explicit flow signaling is therefore not needed).
• The network architecture uses packet classes, such as Diffserv [6].
• The network architecture uses preestablished logi-cal paths from ingress points to egress points, and each new arriving flow at the edge is assigned to one of them. An example of this mechanism is the label-switched paths of the Label Switched Paths of Multiprotocol Label Switching (MPLS) networks [12] when used without a long-term resource reser-vation. Instead, once a flow is accepted by our AC, resources in the logical path are reserved during the flow’s lifetime. We use the logical paths to pin each flow to a route, so that all flow packets follow the path where the reservation has been made.
• In the agreement, each user specifies the desired min-imum throughput of flows (e.g., the same value for all flows), according to the application type (FTP, Web, etc.) or other (avoiding again the use of ex-plicit flow signaling).
Although we focus on a single network service, our view is of a multiservice network where our scheme coexists with low jitter and no loss service for real-time flows, using, for example, scheduling priority in the queues over the elastic flows of our scheme. In the next three sections, we explain the intradomain operation of our scheme, and in the fourth one, we discuss its needs as terms of interconnection with neighboring domains.
3.1 The Intradomain Architecture of the Scheme When the first packet of a new flow arrives to the network, the flow is assigned to a logical path, and the list of active flows is updated at the ingress. The desired throughput of the flow is obtained from the corresponding user-provider agreement. The AC evaluates if this minimum throughput requirement can be provided without losing the minimum throughput guaranteed to the accepted flows. If the flow is accepted, it receives a guaranteed minimum through-put service; if the flow is rejected, it receives a best-effort service.
The kind of AC we propose belongs to the methods based on end-to-end per flow measurements [10, 11], where end points send a special probing flow and measure its experienced QoS to estimate if the available resources in a path are enough to satisfy the flow’s request. After this initial time period, called the AC phase, the AC decision is made: an acceptance or rejection decision is made accord-ing to the measurements and the resources requested by the new flow. A known advantage of measurement-based schemes compared with traffic parameter-based schemes is that using measurements provides a better estimate of the actual traffic load. The main advantage of end-to-end
schemes compared to hop-by-hop schemes is that per flow processing is not needed in the core of the network since edge routers perform the AC. However, these end-to-end measurement-based AC schemes are focused on real-time flows that have different traffic characteristics and QoS re-quirements than elastic TCP flows. Real-time flows have a constant or variable sending rate (but are less variable than elastic flows) and a longer duration, and they require a very small packet loss ratio and small packet delay and jitter. Elastic flows, however, have a very variable sending rate and require a minimum network throughput and can benefit from extra throughput. In these schemes, the special probing flow is an extra flow of packets sent before the AC decision and the data packets. However, in our scheme [4], the first packets of the flow are used as a probing flow to test if the network throughput in a path is enough to satisfy the flow’s request. Moreover, in these schemes, the queues use different priorities for scheduling packets (packets of accepted flows have higher priority than packets of flows in the AC phase), while in our scheme, we use different priorities for discarding packets.
The whole scheme with the AC method uses five packet classes, each one with a different discarding priority. The classes are two A (acceptance) classes, AINand AOUT; two R (requirement) classes, RIN and ROUT; and the BE (best-effort) class. The scheme is the following (Figure 1):
• During the AC phase and at the ingress, packets are marked as R by a traffic meter and a marker: each flow packet is classified as “in” or “out,” de-pending on whether the (measured) average sending rate is smaller or greater than the desired minimum throughput, and then in packets are marked as RIN and out packets as ROUT.
• During the AC phase, at the egress, the throughput of the flow is measured. The measurement is sent to the corresponding ingress through a signaling packet. • At the end of the AC phase, at the ingress, the
mea-sured throughput is compared to the requested min-imum throughput: if it is smaller, the flow is not accepted (otherwise it is).
• After the AC phase, at the ingress, if the flow has been accepted, its packets are marked as A (AINor AOUT, depending on the comparison between the average sending rate and the desired minimum throughput), and if it has been rejected, its packets are marked as BE.
• In the output links of routers, there is a single first in, first out (FIFO) queue (to maintain packet order-ing) with discarding priorities for each class in the following order (from low to high): AIN, RIN, AOUT, ROUTand BE.
The priorities are chosen so that accepted flows are pro-tected against flows that are in the AC phase. Since the
lowest discarding priority class receives the resources first, the next class the remaining ones, and so on, this roughly means that the R class packets must be discarded before the A class packets (A< R). Specifically, the scheme needs the flows in the AC phase to be able to get a measurement of the unreserved throughput in the path (AIN < RIN < AOUT). Moreover, the remaining extra throughput is given to accepted flows rather than to flows that are in the AC phase (AOUT < ROUT).
3.2 The Measurement Process
The throughput of the flow is measured at the egress from the received data packets. A list of active flows being mea-sured is maintained at the egress. That is, when a new flow arrives, it is added to the list, and when the measurement is finished, it is removed. The measured throughput is sim-ply the ratio between the total bytes of the received packets during the measurement period divided byT , the duration of this measurement period. Next, signaling packets carry the throughput measurement to the corresponding ingress. Note that the AC phase duration is equal to the measure-ment durationT plus the packet round-trip time.
It is important to decide on the value ofT . If it is too short, the measurement could be incomplete, but if it is too long, the method might have a tendency to reject too many flows in some situations. In section 4, we use simulations to study the influence of the measurement duration. 3.3 The Requirement of a Minimum Sending Rate In end-to-end measurement-based AC, the reservation of resources for an accepted flow is set up by a special probing flow (in our scheme, the first packets of the flow, marked as RIN during the AC phase), maintained as long as the flow transmits, and then released when it stops. This is because the measurements will reflect all of these situa-tions. We say that per flow reservations are based on “oc-cupancy” instead of “state.” Per flow state is only main-tained at the edge, and per flow processing in the core is not needed. However, in order for the AC to work properly, sources should never send less than the desired minimum throughput. Otherwise, during the AC phase, the measured throughput would surely be smaller than the one requested, and the flow would be rejected; after the AC phase, if an ac-cepted flow does not use the guaranteed throughput, other, newly arriving flows in the AC phase would be erroneously accepted, and the throughput allocated to them later on might be incorrect.
When TCP transfers a file and a minimum throughput is available in the network path, the long-term average of the sending rate during the flow’s lifetime is kept above this minimum throughput. However, the short-term fluc-tuations of the sending rate of a “standard” TCP source, above and below the average, might cause some inaccu-racies that could reduce the performance of the scheme. To avoid this situation, we propose modifying the sending
ingress flow classifier admission controller desired throughput core class classifier FIFO & priority discarding traffic meter & marker flow classifier measured throughput traffic meter egress SLS ingress flow classifier admission controller desired throughput core class classifier FIFO & priority discarding traffic meter & marker flow classifier measured throughput traffic meter egress SLS
Figure 1. Functional block diagram of our scheme
algorithms of TCP to keep the short-term sending rate above a minimum value. The details are explained in sec-tion 4, where we use this modified TCP source for the evaluation of the scheme through simulation. Another op-tion might be to apply some kind of traffic shaping to the input flow at the ingress, add dummy packets, and so on, in order to obtain a flow with the desired short-term min-imum rate. A consequence of this requirement is that at the ingress, the flow’s rate should be checked to see if it is always above the minimum throughput; otherwise, the service should be denied.
3.4 The Interdomain Operation
In a multidomain scenario, the end-to-end service is made available by the concatenation of the service provided by each of the domains of the followed path. Each domain provides the guaranteed minimum throughput service to the flow in its own way (e.g., our scheme) and has a user-provider relationship with its neighboring domains accord-ing to an agreement (SLA). In the previous sections, we dealt with the intradomain operation of our scheme; here we discuss the interdomain aspects and the details of the edge node operation.
For the interconnection of our domain O (the one us-ing our scheme) and the downstream domain D (Fig. 2), we propose the use of signaling packets so that domain D notifies domain O whether it can provide a guaranteed minimum throughput service to the flow or not. This in-formation will be used in domain O in the following way: if the answer is no, then the AC will reject the flow; if the answer is yes, then the AC decision will depend on the throughput measurement. The need for this signaling can be justified by two reasons. Suppose that a flow is accepted in domain O but is rejected in domain D and that signaling is not used. First, domain O would keep a useless reser-vation for the flow, wasting resources that might be used by other flows. Second, domain O would wrongly consider that the flow is receiving the service and that the agreement with the upstream domain U is being satisfied.
Note that we are only discussing the interconnection of our domain with its neighbors, not the reversal. The neigh-bors will certainly need their own, specific operations for the interconnection with other domains (e.g., some signal-ing, traffic conditionsignal-ing, marksignal-ing, or other).
The operations performed at the ingress of our domain are the following:
• Implicit detection of the start and end of flows and updating of the list of active flows
• Assignment of new flows to logical paths
• Obtaining the desired flow’s throughput from the agreement with the upstream domain
• Checking whether both the new request and the cur-rently accepted ones are within the contracted value specified in the agreement
• Making the AC decision, after the reception of signaling from the egress carrying the throughput measurement
• Measuring the corresponding traffic and marking be-fore and after the AC decision, as well as checking whether the flow’s rate is always above the minimum throughput
• Registering of provided services (accepted and re-jected) to the upstream domain for SLS auditing • Other operations related to the interconnection needs
of the upstream domain
On the other hand, the following operations are per-formed at the egress of our domain:
• Implicit detection of the start of flows and updating of the list of active flows
destination source
domain U domain O domain D
IU EU SLA [measure] [yes/no] SLA IO EO ID ED destination source
domain U domain O domain D
IU EU
SLA
[measure] [yes/no] SLA
IO EO ID ED
Figure 2. Interdomain operation of a domain using our scheme with neighboring domains
• Reception of the signaling packets with the yes/no decision from the downstream domain
• Sending signaling packets to the corresponding ingress with the throughput measurement and the yes/no decision
• Registering provided services (accepted and re-jected) by the downstream domain for SLS auditing • Other operations related to the interconnection needs
of the downstream domain
4. Evaluation of the Scheme through Simulation We have implemented our scheme for TCP flows using the ns simulator [13]. We use a modified TCP source that keeps the short-term sending rate above a minimum value. We study the influence of some parameters on the performance in several network topologies using different traffic loads consisting of TCP flows that carry files of varying sizes. We show results for the throughput obtained by the flows as well as for the efficiency in the use of the links’ bandwidth. 4.1 The Modification of the TCP Source
TCP provides reliable data transfer by detecting lost pack-ets and then retransmitting them until they are received correctly. Usually a packet is considered lost (and packet retransmission is triggered from the last acknowledged packet) when the corresponding ACK packet is not re-ceived during a timeout period or when three duplicated ACKs of a previous packet are received [2]. TCP also uses pipelining and the sliding window mechanism (for flow control), a combination that allows the source to have mul-tiple transmitted but yet-to-be-acknowledged packets, with a maximum number equal to the value of the window. On the other hand, TCP uses rate-adaptive algorithms to match the maximum available throughput in the path. When TCP detects that packets are lost, the sending rate is decreased; otherwise, it is increased. Loss detection and the conse-quent rate variations occur at a round-trip time scale. Rate
variations are made according to (congestion control) algo-rithms such as slow start, congestion avoidance, and fast recovery [2]. These algorithms modify the value of the window (from one to the receiver’s advertised window) and produce the desired rate variations because the aver-age sending rate can be seen as the actual window divided by the round-trip time.
We have modified the TCP sources of the ns simulator to send at a minimum rate and to avoid the short-term fluc-tuations of the sending rate. Instead of sending a burst of packets (the ones that would be allowed by the actual win-dow) within approximately the time period of one round trip, packets are sent smoothly within the same time pe-riod. One packet is sent at a certain time ∆t, which is increased and decreased by an algorithm causing the rate variations. The time∆t has a maximum value that guar-antees the minimum desired rate. The variations of∆t are (inversely) proportional to the window (w [bit]) variations of the TCP New-Reno algorithms implemented in the ns simulator. Specifically,
∆t = K w1 [s], w ≥ wmin [bits], K = wminpkt_sizermin [s · bit], (1)
where pkt_size [bit] is the packet length,rmin [bps] is the minimum desired rate, andwiínis the minimumw, with a value to be chosen. Therefore, the sending rate is
r = pkt_size
∆t = rmin
w
wmin [bps], (2) that is, the sending rate is proportional to the window varia-tions of the TCP New-Reno algorithms with a desired min-imum valuermin. Moreover, packet retransmission from the last acknowledged packet is triggered by the usual circum-stances (i.e., when the corresponding ACK packet is not received during a timeout period or when three duplicated ACKs of a previous packet are received) and also when the packet sequence number reaches the end value and the corresponding ACK has not been received yet.
Finally, another feature we have added to the TCP sources is that they consider the users’ impatience; that is, the source stops sending if the transfer time is too high.
4.2 The Functional Blocks of the Scheme
We have added the functional blocks of our scheme (Fig. 1) to the Diffserv module of the ns simulator. At the ingress routers, there is a sending rate meter, a marker, and an admission controller, and at the egress routers, there is a throughput meter. A set of these blocks exists for each arriving flow. Moreover, in the output links of all routers, there is a single FIFO queue with priority discarding.
All the functional blocks have been designed for the traffic sent by the modified TCP source. The sending rate meter uses the algorithm of the token bucket, which is char-acterized by two parameters, the rate in bps and the burst size in bytes (which constitute the input traffic profile of the service). The marker uses five marks to identify the packet classes defined in section 3.1. The throughput meter starts to measure when the first packet of the flow arrives, then it simply counts the total received bytes during the chosen measurement duration, and finally it notifies the ingress router of the throughput measurement (with the corresponding packet delay). The FIFO queue with pri-ority discarding for the five packet classes (according to section 3.1) is based on the drop-tail algorithm: when the queue is full and a new packet arrives, a packet (the one having the highest discarding priority) is discarded.
4.3 Network Topologies and Traffic Model
We use several network topologies (Fig. 3) with different numbers of hops and logical paths. Topology 1 has a bottle-neck link of 2 Mbps (the length of the output queue is 50 packets) and two logical paths between pairs of ingress-egress routers (e0-e3, e2-e3), both with the same packet round-trip time. Topology 2 is equal to topology 1 except that the packet round-trip times of the two logical paths are different. In topology 3, there are three logical paths: e0-e8 with two hops, e1-e5 and e3-e7 with one hop, and two bottleneck links of 2 Mbps. Topology 4 has four log-ical paths—e0-e6, e2-e6, e3-e6, and e5-e6—with similar packet round-trip times but different numbers of hops and two bottleneck links of 2 and 4 Mbps. Finally, topology 5 has six logical paths—e0-e9, e2-e9, e3-e9, e5-e9, e6-e9, and e8-e9—with similar packet round-trip times but dif-ferent numbers of hops and three bottleneck links of 2, 4, and 6 Mbps.
We generate TCP flows that carry a single file from an ingress point to an egress point through a logical path. Each flow is characterized by the file size and the starting time. File sizes are obtained from a Pareto distribution that approximates the heavy tail behavior of the file size distri-bution observed in measurements [1] reasonably well. In all simulations, the Pareto constant (or tail parameter) is
1.1, and the minimum file size is 10 packets (the packet length is 1000 bytes). With these parameters, the distribu-tion has an infinite variance. After generating the values (about 10,000), more than 50% are below 20 packets, the meanσ is about 74 packets, and the maximum may even reach 19,637 packets. Starting times, on the other hand, are obtained from a Poisson arrival process, which is a sim-ple and useful model that has proved to be valid for more realistic scenarios in Ben Fredj et al. [14]. This process is characterized by the parameterλ flow/sec (i.e., the aver-age number of arrivals per second), which we vary to study different loads. Using all these statistical distributions, the average offered traffic load from an ingress point to an egress point through a logical path is equal toλσ bps.
For each logical path, we generate the same quantity of offered traffic, which we vary from 0.05 Mbps to 3 Mbps in steps of 0.3 Mbps, to study underloading and overloading situations in the links. For all TCP flows, we use the same values of the token bucket algorithm, a rate of 90 Kbps and a burst size of two packets, which represents the desired minimum throughput. The user’s impatience is twice the desired file transfer time, which means getting a throughput of approximately 45 Kbps.
4.4 Performance Parameters
The goal of the AC method is to provide the desired min-imum throughput to the maxmin-imum possible number of flows. Therefore, we evaluate the utilization of resources as well as the throughput obtained by flows. First we calculate the throughput of each flow as the ratio between the total received packets divided by the flow’s lifetime. Then we consider the satisfied flows, defined as the ones that com-plete the file transfer and get at least 95% of the desired minimum throughput (85.5 Kbps). We obtain three perfor-mance parameters for each logical path: the average “total” satisfied traffic load, which is the aggregated throughput of all satisfied flows, taking into account the minimum and the extra throughput; the average “minimum” satisfied traffic load, which takes into account only the minimum through-put; and the average throughput of satisfied flows (which will always be a value above 85.5 Kbps). The first param-eter evaluates the total use of resources, the second one indicates its reserved use, and the third one indicates how much extra throughput the satisfied flows get.
The average values of satisfied traffic load are obtained by averaging over the simulation time but without consid-ering the initial period of the simulation transient phase. We make 10 independent replications of each simulation, where independence is accomplished by using different seeds of the random generator (proposed by L’Ecuyer, with code from [15]). The simulation length is chosen so that af-ter the initial transient period, a minimum of 10,000 flows is generated. From the 10 results, we estimate the mean value by computing the sample mean and the 95% confi-dence interval [15].
2 Mbps 20 ms 50 pkts e0 e2 c1 e3 s4 s6 d5 d7 20 Mbps t1 ms 20 Mbpst2 ms Topology 1: t1 = t2 = 20 ms Topology 2: t1 = t2 = 1 ms
Rest of the links: 20 Mbps, 20 ms
6 Mbps 20 ms 50 pkts e3 e5 c4 e6 e8 c7 s14 e9 s16 s18 s20 4 Mbps 1 ms 50 pkts d13 d15 d17 d19 e0 e2 c1 s10 s12 2 Mbps 1 ms 50 pkts d21 d11 Topology 5 Topology 3 e3 e5 c4 e7 c6 s13 e8 d12 d14 2 Mbps 20 ms 50 pkts d10 e1 c2 s11 2 Mbps 20 ms 50 pkts e0 s9 e3 e5 c4 s11 e6 s13 4 Mbps 20 ms 50 pkts d8 d10 d12 d14 e0 e2 c1 s7 s9 2 Mbps 1 ms 50 pkts Topology 4 2 Mbps 20 ms 50 pkts e0 e2 c1 e3 s4 s6 d5 d7 20 Mbps t1 ms 20 Mbpst2 ms Topology 1: t1 = t2 = 20 ms Topology 2: t1 = t2 = 1 ms
Rest of the links: 20 Mbps, 20 ms
6 Mbps 20 ms 50 pkts e3 e5 c4 e6 e8 c7 s14 e9 s16 s18 s20 4 Mbps 1 ms 50 pkts d13 d15 d17 d19 e0 e2 c1 s10 s12 2 Mbps 1 ms 50 pkts d21 d11 Topology 5 Topology 3 e3 e5 c4 e7 c6 s13 e8 d12 d14 2 Mbps 20 ms 50 pkts d10 e1 c2 s11 2 Mbps 20 ms 50 pkts e0 s9 e3 e5 c4 s11 e6 s13 4 Mbps 20 ms 50 pkts d8 d10 d12 d14 e0 e2 c1 s7 s9 2 Mbps 1 ms 50 pkts Topology 4
Figure 3. Network topologies 1, 2, 3, 4, and 5, showing the link’s bandwidth and delay and the length of queues
4.5 Simulation Results
We have evaluated our scheme through simulation in 10 scenarios using topologies 1 to 5. The results are shown in Figures 4 to 13. In each figure, we show the total satis-fied traffic, the minimum satissatis-fied traffic, and the average throughput of satisfied flows for a logical path versus the average offered traffic (λσ bps). We compare the results obtained by our scheme with the ideal results that would be obtained by a classical hop-by-hop AC method. We ob-tain this theoretical result by taking into account that in our topologies, the blocking probability in each core link is the same and that the offered traffic for each logical path is also the same. The ideal results are represented by dashed lines in the curves of the total satisfied traffic. Note that, in congestion, if the maximum utilization was achieved, the minimum and the total satisfied traffic would be simi-lar and near the ideal result, and the average throughput of satisfied flows would be around 90 Kbps.
In the first scenario, we compare our scheme (using measurement durationsT03= T23= 0.2 sec) with the best-effort service in topology 1 (Fig. 4). As expected in un-derloading, when network resources are enough to satisfy all flows, our scheme achieves the same value for the total
satisfied traffic as the best-effort service, which at the same time is equal to the offered traffic (and to the ideal result). In overloading, our scheme achieves higher utilization, which remains almost constant (above 0.9 Mbps, the ideal being 1 Mbps) for the entire range of offered traffic loads, while the best-effort service achieves utilization tending to zero. On the other hand, the average throughput of satisfied flows decreases for high values of the offered traffic because the unreserved resources decrease. Note also that our scheme achieves almost the same results for the two logical paths. In the second scenario, we study in detail if our scheme guarantees the minimum requested throughput to the ac-cepted flows. We have analyzed the simulation results to obtain the percentage of accepted flows that complete the file transfer, the percentage of accepted flows that are satis-fied (the ones that complete the file transfer and get at least the threshold throughput—95% of the desired minimum throughput), and the frequency distribution of the through-put of the accepted flows to know how far the accepted and nonsatisfied flows are from the threshold throughput. The following is a summary of the results: (1) all accepted flows complete the file transfer, (2) a high percentage of ac-cepted flows are satisfied, and (3) a high percentage of the accepted and nonsatisfied flows achieve a throughput close
e0-e3 e2-e3 e0-e3 e2-e3 our scheme: e0-e3 e2-e3 best-effort: e0-e3 e2-e3 our scheme: best-effort:
Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 4. Comparison of our scheme with the best-effort
service, in topology 1 (T03= T23=0.2 sec)
to the threshold. In Figure 5, we show some of these re-sults, using topology 1 andT03= T23= 0.2 sec. The graph on the top shows percentages of accepted flows versus the offered traffic. The percentage of accepted flows that are satisfied is 100% for a great range of offered traffic, and then it decreases slowly for high values. In the graph on the right, we show the frequency distribution of throughput of accepted flows (the dashed line indicates the threshold throughput of 85.5 Kbps) when the offered traffic load is 3 Mbps (the worst case). Although about 28% of flows are not satisfied, a throughput smaller than 76.5 Kbps is achieved just by 2% of flows, which is a very small value.
accepted & non-satisfied accepted & satisfied accepted & non-satisfied accepted & satisfied
% over the accepted flows 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) accepted accepted Frequency distribution 0.00 0.05 0.10 0.15 0.20 0.25 0.30 0.35 60 70 80 90 100 110 120 Throughput (Kbps)
Figure 5. On the top, the percentage of satisfied flows and
nonsatisfied flows versus the offered traffic load. On the bot-tom, the frequency distribution of the throughput of accepted flows when the offered traffic is 3 Mbps. The topology is 1, withT03= T23=0.2 sec.
In the third scenario, we study the ability of our scheme to provide different minimum throughput to flows from different users. This is because our scheme differentiates between the “in” and the “out” traffic of the flow. In topol-ogy 1, we consider two users, A and B, with desired min-imum throughput of 90 and 135 Kbps, respectively. User A sends flows through the logical path e0-e3 and user B through e2-e3. For each user, the average offered traffic varies from 0 to 3 Mbps, andT03= T23= 0.2 sec. In Fig-ure 6, we show the results for the traffic of each user. Our scheme achieves the desired different average throughputs (the final values are about 94 and 139 Kbps) and approxi-mately similar link utilization.
In the fourth scenario, we study the ability of our scheme to provide protection against nonresponsive sources. This is because our scheme differentiates between the “in” and the “out” traffic of the flow. We send TCP flows together
90 Kbps 135 Kbps 90 Kbps 135 Kbps Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 115 140 165 190 215 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 6. Two users asking for different values of minimum
throughput: 90 Kbps for user A and 135 Kbps for user B (in topology 1, withT03= T23=0.2 sec)
with CBR (constant bit rate) flows. The desired minimum throughput of all flows (TCP and CBR) is 90 Kbps, but CBR flows have a constant rate of 135 Kbps while TCP flows adjust the sending rate. CBR flows are generated in a similar way as TCP flows: (1) the starting times are obtained from a Poisson arrival process (characterized by λ flow/sec, the average number of arrivals per second); (2) the time duration is f_s/r, where r is the flow’s rate (135 Kbps), and f_s is a file size (bits) obtained from a Pareto distribution with the same parameters used for the TCP flows; and (3) therefore, the average offered traffic load is againλσ bps. In this scenario, we use topology 1,
and we send TCP flows through the logical path e0-e3 and CBR flows through e2-e3. In each path, the average of-fered traffic (λσ) is the same and varies from 0 to 3 Mbps, andT03= T23 = 0.2 sec. In Figure 7, we show the results for the TCP and CBR flows. Each logical path achieves approximately similar link utilization. The accepted TCP and CBR flows achieve the desired minimum throughput even though CBR flows are sending constantly at a higher rate. However, the extra throughput (above 90 Kbps) is different: unreserved resources are shared fairly among only CBR flows because they do not adjust the sending rate as TCP but with a maximum per flow’s throughput of 135 Kbps, and the rest is shared fairly among TCP flows.
In the fifth scenario, we study the influence of the mea-surement durationT (= T03= T23) on the performance of the scheme in topology 1 (Fig. 8). We have used four dif-ferent values ofT : 0.04, 0.2, 0.5, and 0.9 sec. For clarity, we only show the results for the logical path e0-e3, but they are similar for the e2-e3 pair. The best performance is achieved withT = 0.2 sec. When T is too short (0.04 sec), the measurements are wrong, and the performance is very bad. Moreover, the results show that increasingT (0.5 and 0.9 sec) produces a worse performance.
The reason for the behavior of the curves in Figure 8 is that our AC method rejects too many flows in situations where a lot of flows simultaneously meet during the AC phase. Imagine a situation in which the AC phases of a set of flows overlap in time, and these flows have a com-mon bottleneck link—that is, their total desired through-put is greater than the available one (the total RIN traffic exceeds the available throughput). This available through-put is then shared among the flows proportionally to their desired throughputs, and the measured throughput of each flow is smaller than the desired one. The AC rejects all flows, and some decisions are therefore erroneous. Specif-ically, the number of affected flows depends on how strong the overlapping of the AC phases is since the more the flows overlap, the more flows are erroneously rejected. An in-crease in the value ofT causes an increase in the number of flows that overlap and also in the number of erroneous AC decisions. Moreover, this also happens when the flow’s ar-rival rateλ increases. In conclusion, our scheme performs better using a measurement duration that is short, but there is a limit, because if it is too short, the measurements are wrong.
In the sixth scenario, we study the fairness in the sharing between logical paths, using topology 1 andT03 = T23 = 0.2 sec (Fig. 9). We keep the offered traffic of the logical path e0-e3 constant at 1 Mbps and vary the offered traffic of the logical path e2-e3 from 0.05 to 3 Mbps. We expect that the 2 Mbps of the bottleneck link will be shared between the two logical paths proportionally to their respective offered traffic (indicated by the dashed lines of the ideal result in Figure 9). Note that the simulation results are quite close to the expected results.
In the seventh scenario, we study the influence of the packet round-trip time (for hosts and for ingress-egress
TCP CBR TCP CBR Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 7. Protection of TCP flows against constant bit rate
(CBR) flows of 135 Kbps, in topology 1, when the desired minimum throughput for all flows is 90 Kbps, andT03= T23=
0.2 sec
routers) on the performance of our scheme (Fig. 10). We use topology 2, where the packet round-trip time of edge routers and the packet round-trip time of hosts for the logi-cal path e0-e3 (84 and 160 msec, respectively) are approx-imately twice that of the one for e2-e3 (42 and 80 msec, respectively). The measurement duration isT03 = T23 = 0.2 sec. The simulation results show that the performance is very similar for the two logical paths.
0.9 s 0.04 s 0.2 s 0.5 s 0.9 s 0.04 s 0.2 s 0.5 s Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 8. The influence of the measurement durationT on the performance of our scheme, in topology 1 (T = T03 = T23),
and for logical path e0-e3
In the eighth to tenth scenarios, we study the influence of the number of hops of the logical paths on the perfor-mance of our scheme, using topology 3 (Fig. 11), topol-ogy 4 (Fig. 12), and topoltopol-ogy 5 (Fig. 13). The measurement durations are the following: in topology 3,T15= T37= 0.2 sec (1 hop) andT08= 0.4 sec (2 hops); in topology 4, T36= T56= 0.2 sec (1 hop) and T06= T26= 0.4 s (2 hops); and in topology 5,T69 = T89 = 0.2 sec (1 hop), T39 = T59 = 0.4 sec (2 hops), andT09 = T29 = 0.5 sec (3 hops). In Figure 13, for clarity, we only show the results for the “up” pairs—e0-e9, e3-e9, and e6-e9—but they are similar for the corresponding “down” pairs (e2-e9, e5-e9, and
e8-e0-e3 e2-e3 e0-e3 e2-e3 Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 9. Sharing between logical paths in topology 1 (with T03= T23=0.2 sec). The offered traffic of e0-e3 is Mbps.
e9). The results show that in congestion, the logical paths with fewer hops obtain a greater utilization than the logi-cal paths with more hops. Logilogi-cal paths with multiple hops obtain a smaller value of satisfied traffic since flows pass-ing through multiple congested links experience a higher blocking probability. This is a known behavior in classi-cal hop-by-hop AC schemes and end-to-end measurement-based AC schemes [11]. Note that the simulation results for the three topologies are close to the ideal results for each of the logical paths, although the total utilization is a bit lower. e0-e3 e2-e3 e0-e3 e2-e3 Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 10. The influence of the packet round-trip time on
the performance of our scheme, in topology 2 (T03 = T23 =
0.2 sec)
5. Conclusions
We have proposed a new scheme for a network service that guarantees a minimum throughput to flows accepted by AC and is suitable for TCP flows. It considers a network path and is able to provide different throughput to different flows (users) as well as protection against nonresponsive sources. The scheme is simple and scalable because in the core, it does not need per flow processing and uses a small set of packet classes, with each class having a different dis-carding priority. The AC method is based on edge-to-edge
e3-e7 e0-e8 e1-e5 e3-e7 e0-e8 e1-e5 Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 11. The influence of the number of hops on the
performance of our scheme, in topology 3 (T08 = 0.4 sec,
T15= T37=0.2 sec)
per flow throughput measurements using the first packets of the flow. Moreover, it requires flows to send at a min-imum rate since reservations are based on “occupancy” rather than on “state.” On the other hand, we have consid-ered a scenario with multiple domains, where each domain has a user-provider agreement with each of its neighboring domains, and we have discussed the interconnection needs of our scheme and the details of the edge node operation. We have evaluated the scheme through simulation in several network topologies. We have used different traffic loads of TCP flows carrying files of varying sizes, using
e0-e6 e2-e6 e3-e6 e5-e6 e0-e6 e2-e6 e3-e6 e5-e6
Total traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 12. The influence of the number of hops on the
performance of our scheme, in topology 4 (T36 = T56 =
0.2 sec,T06= T26=0.4 sec)
a modified TCP source that keeps the short-term sending rate above a minimum value. The results confirm that the scheme guarantees the minimum requested throughput to the flows and achieves a high value of the utilization of net-work resources. We have seen that it provides the desired minimum throughput to much more flows than the best-effort service. We have also seen that it is able to provide different minimum throughput to different users and pro-tection against nonresponsive sources. We have also stud-ied the influence of the measurement duration and shown that the scheme obtains a better performance using a short
e6-e9 e0-e9 e3-e9 e6-e9 e0-e9 e3-e9 Total traffic (Mbps) 0.0 0.3 0.6 0.9 1.2 1.5 1.8 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Minimum traffic (Mbps) 0.0 0.3 0.6 0.9 1.2 1.5 1.8 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps) Average throughput (Kbps) 90 110 130 150 170 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Offered traffic (Mbps)
Figure 13. The influence of the number of hops on the
perfor-mance, for the paths e0-e9, e3-e9, and e6-e9, in topology 5 (T09= T29= 0.5sec,T39= T59=0.4 sec,T69= T89=0.2 sec)
measurement duration (but with a limit). We have also shown that it achieves fairness in the sharing between the ingress-egress pairs even when there are different round-trip times. Finally, we have seen that our scheme discrim-inates against the multihop flows, but this is similar to the behavior observed in classical hop-by-hop or in end-to-end AC schemes.
6. Acknowledgments
This work was partially supported by the MCYT (Span-ish Science and Technology Ministry) research project
TIC2003-05567 and the Generalitat of Catalonia’s research support program (SGR 00296).
7. References
[1] Brownlee, N., and K. C. Claffy. 2002. Understanding Internet traffic streams: Dragonflies and tortoises. IEEE Communications
Mag-azine 40(10):110-17.
[2] Jacobson, V. 1998. Congestion avoidance and control. ACM Computer
Communication Review 18(4):314-29.
[3] Roberts, J. W., and L. Massoulié. 1999. Arguments in favor of ad-mission control for TCP flows. In Proceedings of the 1999 16th
ITC.
[4] Fàbrega, Ll., T. Jové, andY. Donoso. 2003. Throughput guarantees for elastic flows using end-to-end admission control. In Proceedings
of the 2003 IFIP/ACM LANC.
[5] Clark, D. D., and W. Fang. 1998. Explicit allocation of best-effort packet delivery service. In IEEE/ACM Transactions on
Network-ing.
[6] Blake, S., D. Black, M. Carlson, E. Davies, W. Weiss, and Z. Wang. 1998. An architecture for Differentiated Services. RFC 2475. [7] Mortier, R., I. Pratt, C. Clark, and S. Crosby. 2000. Implicit
admis-sion control. IEEE Journal on Selected Areas in Communications 18(12):2629-39.
[8] Kumar, A., M. Hegde, S. V. R. Anand, B. N. Bindu, D. Thirumurthy, and A. A. Kherani. 2000. Nonintrusive TCP connection admission control for bandwidth management of an Internet access link.
IEEE Communications Magazine 38(5):160-7.
[9] Ben Fredj, S., S. Oueslati-Boulahia, and J. W. Roberts. 2001. Measurement-based admission control for elastic traffic. In
Pro-ceedings of the 2001 ITC 17.
[10] Bianchi, G., A. Capone, and C. Petrioli. 2000. Throughput analy-sis of end-to-end measurement-based admission control in IP. In
Proceedings of the 2000 INFOCOM.
[11] Breslau, L., E. Knightly, S. Shenker, I. Stoica, and H. Zhang. 2000. Endpoint admission control: Architectural issues and per-formance. In Proceedings of the 2000 ACM SIGCOMM. [12] Rosen, E., A. Viswanathan, and R. Callon. 2001. Multiprotocol label
switching architecture. RFC 3031.
[13] UCB/LBL/VINT Network Simulator—ns (version 2). http://www. isi.edu/nsnam/ns/
[14] Ben Fredj, S., T. Bonald, A. Proutière, G. Régnié, and J. W. Roberts. 2001. Statistical bandwidth sharing: A study of congestion at flow level. In Proceedings of the 2001 ACM SIGCOMM.
[15] Law, A. M., and W. David Kelton. 2000. Simulation modeling and
analysis. New York: McGraw-Hill.
Lluís Fàbrega received a degree in telecommunications engi-neering from the Polytechnical University of Catalonia (Spain) in 1995. He is currently a PhD student in the Broadband Com-munications and Distributed Systems (BCDS) research group at the Institute of Informatics and Applications at the University of Girona (Spain). He is also an associate lecturer in the Elec-tronics, Informatics and Automatics Department at the Univer-sity of Girona. His current teaching duties include graduate-level courses on computer communication networks. His research in-terests are quality of service on the Internet, specifically for elastic traffic. He has worked on several national projects of the Spanish Ministry of Education and Science.
Teodor Jové has been a senior lecturer in the Electronics, Infor-matics and AutoInfor-matics Department at the University of Girona
(Spain) since 1993, where he is also a member of the Broad-band Communications and Distributed Systems (BCDS) research group at the Institute of Informatics and Applications. He received his PhD degree in computer science from the Polytechnical Uni-versity of Catalonia in 1989. He was a senior lecturer in the Computer Architecture Department of the Polytechnical Univer-sity of Catalonia from 1989 to 1993. He has been involved in the management of both universities, especially as a vice-rector of information and communication technologies, at the University of Girona. His current teaching duties include graduate and post-graduate-level courses on operating systems, distributed systems, and computer architecture. His research interests are in the fields of management of communication networks, MPLS and GMPLS, distributed simulation, and distributed systems. He has coordi-nated and worked on several national projects of the Spanish Ministry of Education and Science.
Pere Vilà has been a computer science researcher and associate lecturer in the Electronics, Informatics and Automatics Depart-ment of the University of Girona (Spain) since 1998, where he is a member of the Broadband Communications and Distributed Sys-tems research group (BCDS) at the Institute of Informatics and Applications. He has a PhD in computer science from the Uni-versity of Girona (2004). His research interests are in the fields of management and performance evaluation of communication networks, distributed network management based on intelligent agents, and MPLS and GMPLS. He has coauthored more than 30 papers in journals and international conferences. He has car-ried out research stays at the University of Strathclyde (Glas-gow) and Queen Mary College (London). He has worked on sev-eral national projects of the Spanish Ministry of Education and Science.
José Marzo is a senior lecturer in the Electronics, Informatics and Automatics Department of the University of Girona, Spain. He received his PhD degree in industrial engineering from the University of Girona in 1997. From 1978 to 1991, he was with Telefonica, the main telephone operator in Spain, working as the head of the engineering department and head of the planning and programming office in Girona, among other technical tasks. His current teaching duties include graduate and post-graduate-level courses on operating systems, computer communication networks, and performance evaluation of telecommunication sys-tems. His research interests are in the fields of management and performance evaluation of communication networks, network management based on intelligent agents, MPLS and GMPLS, and distributed simulation. He leads the Broadband Communi-cations and Distributed Systems (BCDS) research group at the Institute of Informatics and Applications (at the University of Girona). He coordinated the participation of this research group in some national Spanish research projects. He has recently been involved in some European projects on distance education. He is currently the coordinator of the Spanish Network of Excellence in MPLS/GMPLS networks, which involves several Spanish insti-tutions. He is a member of the IEEE Communications Society. He has participated in the technical program committees and chair-ing sessions of several conferences, includchair-ing SPECTS, IEEE Globecom, ICC, and Infocom. He serves on the editorial board of the International Journal of Communication Systems. He has coauthored several papers published in international journals and made presentations in leading international conferences.