Throughput Guarantees for TCP Flows in a Network Based on Packet Classes Using Edge-to-Edge Per Flow Measurements

Transcription

1 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 71 Girona, Spain fabrega@eia.udg.es 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 guaranteed 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 applications 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 The Society for Modeling and Simulation International DOI: / the network, the decisive quality-of-service (QoS) parameter 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 network input link) to match the maximum available throughput in the network path. Since the available throughput changes over time, TCP uses rate-adaptive algorithms that increase and decrease the sending rate to match these variations and minimize packet loss. TCP increases the sending 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 Volume 82, Number 6 SIMULATION 383

2 Fàbrega, Jové, Vilà, and Marzo high-layer protocols impose a limit on the file transfer time, and if it is exceeded, the transaction is aborted. This situation 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 performance 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 minimum 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 (minimum) 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 review related work; in section 3, we describe our scheme, including the AC method; and in section 4, we present simulation results using TCP flows in several network topologies. Finally, we summarize the article in section 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 provides 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 demands exceed network resources), this scheme cannot provide 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) architecture [6], which keeps the per flow state at the edge but not in the core, making the network more simple and scalable. 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 overload does occur, the provided throughput to each flow is a share of the bottleneck link s bandwidth that is proportional 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 Service cannot provide a desired minimum throughput to any flow. Congestion could be avoided using resource overprovisioning or, in other words, dimensioning network resources so that they are never exceeded by users demands. However, 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 having 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 decision, 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 384 SIMULATION Volume 82, Number 6

3 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 accepted 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 estimate. 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 connection, 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 following 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 complete 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 logical 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 reservation. 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 minimum 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 explicit 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 throughput 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 according 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 Volume 82, Number 6 SIMULATION 385

4 Fàbrega, Jové, Vilà, and Marzo 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 requirements 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, A IN and A OUT ;two R (requirement) classes, R IN and R OUT ; and the BE (besteffort) 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, depending on whether the (measured) average sending rate is smaller or greater than the desired minimum throughput, and then in packets are marked as R IN and out packets as R OUT. During theac 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 measured throughput is compared to the requested minimum throughput: if it is smaller, the flow is not accepted (otherwise it is). After theac phase, at the ingress, if the flow has been accepted, its packets are marked as A (A IN or A OUT, 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 ordering) with discarding priorities for each class in the following order (from low to high): A IN,R IN,A OUT, R OUT and BE. The priorities are chosen so that accepted flows are protected 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 thea 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 (A IN < R IN < A OUT ). Moreover, the remaining extra throughput is given to accepted flows rather than to flows that are in the AC phase (A OUT < R OUT ). 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 measured 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 simply the ratio between the total bytes of the received packets during the measurement period divided by T, 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 measurement duration T plus the packet round-trip time. It is important to decide on the value of T.Ifitistoo 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 R IN 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 situations. We say that per flow reservations are based on occupancy instead of state. Per flow state is only maintained 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 theac phase, if an accepted 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 fluctuations of the sending rate of a standard TCP source, above and below the average, might cause some inaccuracies that could reduce the performance of the scheme. To avoid this situation, we propose modifying the sending 386 SIMULATION Volume 82, Number 6

5 SLS desired throughput admission controller ingress core egress measured throughput flow classifier traffic meter & marker class classifier FIFO & priority discarding flow classifier traffic meter 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 section 4, where we use this modified TCP source for the evaluation of the scheme through simulation. Another option 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 minimum 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 userprovider relationship with its neighboring domains according 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 using 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 information 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 reservation 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 neighbors will certainly need their own, specific operations for the interconnection with other domains (e.g., some signaling, traffic conditioning, marking, 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 currently 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 before 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 rejected) 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 performed at the egress of our domain: Implicit detection of the start of flows and updating of the list of active flows The measurement of the flow s throughput Volume 82, Number 6 SIMULATION 387

6 Fàbrega, Jové, Vilà, and Marzo domain U domain O domain D source SLA I U E U destination I O E O SLA I D E D [measure] [yes/no] 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 rejected) 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 packets 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 received 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 multiple 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 consequent rate variations occur at a round-trip time scale. Rate variations are made according to (congestion control) algorithms 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 average 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 fluctuations of the sending rate. Instead of sending a burst of packets (the ones that would be allowed by the actual window) within approximately the time period of one round trip, packets are sent smoothly within the same time period. 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 guarantees 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 1 w [s], w w min [bits], pkt_size K = w min [s bit], (1) r min where pkt_size [bit] is the packet length, r min [bps] is the minimum desired rate, and w iín is the minimum w, with a value to be chosen. Therefore, the sending rate is r = pkt_size t = r min w w min [bps], (2) that is, the sending rate is proportional to the window variations of the TCP New-Reno algorithms with a desired minimum value r min. Moreover, packet retransmission from the last acknowledged packet is triggered by the usual circumstances (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. 388 SIMULATION Volume 82, Number 6

7 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 characterized 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 priority 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 bottleneck link of 2 Mbps (the length of the output queue is 50 packets) and two logical paths between pairs of ingressegress 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 logical 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 different 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 distribution 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 distribution 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 simple 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 average 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 5 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 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 minimum throughput to the maximum 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 complete the file transfer and get at least 95% of the desired minimum throughput (85.5 Kbps). We obtain three performance 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 throughput; and the average throughput of satisfied flows (which will always be a value above 85.5 Kbps). The first parameter 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 considering 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 after 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% confidence interval [15]. Volume 82, Number 6 SIMULATION 389

8 Fàbrega, Jové, Vilà, and Marzo s4 Topology 1: t1 = t2 = 20 ms Topology 2: t1 = t2 = 1 ms s11 s13 Topology 3 e0 e1 e3 20 Mbps t1 ms c1 e2 2 Mbps 20 ms e3 20 Mbps t2 ms d5 d7 s9 e0 c2 2 Mbps 20 ms c4 e5 2 Mbps 20 ms c6 e7 e8 d10 s6 d12 d14 s7 s11 Topology 4 s10 s14 s18 Topology 5 d11 e0 e3 d8 e0 e3 e6 d13 c1 e2 2 Mbps 1 ms c4 e5 4 Mbps 20 ms e6 d10 d12 d14 c1 e2 2 Mbps 1 ms c4 e5 4 Mbps 1 ms c7 e8 6 Mbps 20 ms e9 d15 d17 d19 s9 s13 s12 s16 s20 d21 Rest of the links: 20 Mbps, 20 ms 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 satisfied traffic, the minimum satisfied 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 obtain 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 similar and near the ideal result, and the average throughput of satisfied flows would be around Kbps. In the first scenario, we compare our scheme (using measurement durations T 03 = T 23 = sec) with the besteffort service in topology 1 (Fig. 4). As expected in underloading, 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 accepted 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 satisfied (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 throughput 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 accepted flows are satisfied, and (3) a high percentage of the accepted and nonsatisfied flows achieve a throughput close 3 SIMULATION Volume 82, Number 6

9 our scheme: e0-e3 e2-e3 best-effort: e0-e3 e2-e3 accepted & satisfied accepted & non-satisfied % over the accepted flows Frequency distribution accepted Throughput (Kbps) Figure 5. On the top, the percentage of satisfied flows and nonsatisfied flows versus the offered traffic load. On the bottom, the frequency distribution of the throughput of accepted flows when the offered traffic is 3 Mbps. The topology is 1, with T 03 = T 23 = sec. Figure 4. Comparison of our scheme with the best-effort service, in topology 1 (T 03 = T 23 = sec) to the threshold. In Figure 5, we show some of these results, using topology 1 and T 03 = T 23 = 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. 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 topology 1, we consider two users, A and B, with desired minimum throughput of 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, and T 03 = T 23 = sec. In Figure 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 approximately 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 Volume 82, Number 6 SIMULATION 391

10 Fàbrega, Jové, Vilà, and Marzo Kbps 135 Kbps Figure 6. Two users asking for different values of minimum throughput: Kbps for user A and 135 Kbps for user B (in topology 1, with T 03 = T 23 = sec) with CBR (constant bit rate) flows. The desired minimum throughput of all flows (TCP and CBR) is 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 offered traffic (λσ) is the same and varies from 0 to 3 Mbps, and T 03 = T 23 = 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 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 measurement duration T (= T 03 = T 23 ) on the performance of the scheme in topology 1 (Fig. 8). We have used four different values of T : 4,, 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 with T = sec. When T is too short (4 sec), the measurements are wrong, and the performance is very bad. Moreover, the results show that increasing T (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 common bottleneck link that is, their total desired throughput is greater than the available one (the total R IN traffic exceeds the available throughput). This available throughput 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. Specifically, the number of affected flows depends on how strong the overlapping of theac phases is since the more the flows overlap, the more flows are erroneously rejected. An increase in the value of T 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 arrival 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 and T 03 = T 23 = 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 5 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 392 SIMULATION Volume 82, Number 6

11 TCP CBR 4 s s 0.5 s 0.9 s 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 Kbps, and T 03 = T 23 = 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 logical path e0-e3 (84 and 160 msec, respectively) are approximately twice that of the one for e2-e3 (42 and 80 msec, respectively). The measurement duration is T 03 = T 23 = sec. The simulation results show that the performance is very similar for the two logical paths. Figure 8. The influence of the measurement duration T on the performance of our scheme, in topology 1 (T = T 03 = T 23 ), 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 performance of our scheme, using topology 3 (Fig. 11), topology 4 (Fig. 12), and topology 5 (Fig. 13). The measurement durations are the following: in topology 3, T 15 = T 37 = sec (1 hop) and T 08 = sec (2 hops); in topology 4, T 36 = T 56 = sec (1 hop) and T 06 = T 26 = s (2 hops); and in topology 5, T 69 = T 89 = sec (1 hop), T 39 = T 59 = sec (2 hops), and T 09 = T 29 = 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- Volume 82, Number 6 SIMULATION 393

12 Fàbrega, Jové, Vilà, and Marzo e0-e3 e2-e3 e0-e3 e2-e Figure 9. Sharing between logical paths in topology 1 (with T 03 = T 23 = sec). The offered traffic of e0-e3 is Mbps. Figure 10. The influence of the packet round-trip time on the performance of our scheme, in topology 2 (T 03 = T 23 = sec) e9). The results show that in congestion, the logical paths with fewer hops obtain a greater utilization than the logical paths with more hops. Logical paths with multiple hops obtain a smaller value of satisfied traffic since flows passing through multiple congested links experience a higher blocking probability. This is a known behavior in classical hop-by-hop AC schemes and end-to-end measurementbased 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. 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 discarding priority. The AC method is based on edge-to-edge 394 SIMULATION Volume 82, Number 6

13 e0-e8 e1-e5 e3-e Figure 11. The influence of the number of hops on the performance of our scheme, in topology 3 (T 08 = sec, T 15 = T 37 = sec) 1.4 e0-e6 e2-e6 e3-e6 e5-e6 1.4 Figure 12. The influence of the number of hops on the performance of our scheme, in topology 4 (T 36 = T 56 = sec, T 06 = T 26 = sec) per flow throughput measurements using the first packets of the flow. Moreover, it requires flows to send at a minimum rate since reservations are based on occupancy rather than on state. On the other hand, we have considered 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 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 network resources. We have seen that it provides the desired minimum throughput to much more flows than the besteffort service. We have also seen that it is able to provide different minimum throughput to different users and protection against nonresponsive sources. We have also studied the influence of the measurement duration and shown that the scheme obtains a better performance using a short Volume 82, Number 6 SIMULATION 395

14 Fàbrega, Jové, Vilà, and Marzo 1.8 e0-e9 e3-e9 e6-e9 TIC and the Generalitat of Catalonia s research support program (SGR 00296) Figure 13. The influence of the number of hops on the performance, for the paths e0-e9, e3-e9, and e6-e9, in topology 5 (T 09 = T 29 = 0.5 sec, T 39 = T 59 = sec, T 69 = T 89 = 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 roundtrip times. Finally, we have seen that our scheme discriminates 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 7. References [1] Brownlee, N., and K. C. Claffy Understanding Internet traffic streams: Dragonflies and tortoises. IEEE Communications Magazine 40(10):-17. [2] Jacobson,V Congestion avoidance and control. ACM Computer Communication Review 18(4): [3] Roberts, J. W., and L. Massoulié Arguments in favor of admission control for TCP flows. In Proceedings of the th ITC. [4] Fàbrega, Ll., T. Jové, andy. Donoso 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 Explicit allocation of best-effort packet delivery service. In IEEE/ACM Transactions on Networking. [6] Blake, S., D. Black, M. Carlson, E. Davies, W. Weiss, and Z. Wang An architecture for Differentiated Services. RFC [7] Mortier, R., I. Pratt, C. Clark, and S. Crosby Implicit admission control. IEEE Journal on Selected Areas in Communications 18(12): [8] Kumar, A., M. Hegde, S. V. R. Anand, B. N. Bindu, D. Thirumurthy, anda. A. Kherani Nonintrusive TCP connection admission control for bandwidth management of an Internet access link. IEEE Communications Magazine 38(5): [9] Ben Fredj, S., S. Oueslati-Boulahia, and J. W. Roberts Measurement-based admission control for elastic traffic. In Proceedings of the 2001 ITC 17. [10] Bianchi, G., A. Capone, and C. Petrioli Throughput analysis 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 Endpoint admission control: Architectural issues and performance. In Proceedings of the 2000 ACM SIGCOMM. [12] Rosen, E., A. Viswanathan, and R. Callon Multiprotocol label switching architecture. RFC [13] UCB/LBL/VINT Network Simulator ns (version 2). isi.edu/nsnam/ns/ [14] Ben Fredj, S., T. Bonald, A. Proutière, G. Régnié, and J. W. Roberts 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 Simulation modeling and analysis. New York: McGraw-Hill. Lluís Fàbrega received a degree in telecommunications engineering from the Polytechnical University of Catalonia (Spain) in He is currently a PhD student in the Broadband Communications 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 Electronics, Informatics and Automatics Department at the University of Girona. His current teaching duties include graduate-level courses on computer communication networks. His research interests 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. This work was partially supported by the MCYT (Spanish Science and Technology Ministry) research project Teodor Jové has been a senior lecturer in the Electronics, Informatics and Automatics Department at the University of Girona 396 SIMULATION Volume 82, Number 6

15 (Spain) since 1993, where he is also a member of the Broadband 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 University of Catalonia in He was a senior lecturer in the Computer Architecture Department of the Polytechnical University of Catalonia from 1989 to 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 postgraduate-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 coordinated 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 Department of the University of Girona (Spain) since 1998, where he is a member of the Broadband Communications and Distributed Systems research group (BCDS) at the Institute of Informatics and Applications. He has a PhD in computer science from the University 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 carried out research stays at the University of Strathclyde (Glasgow) and Queen Mary College (London). He has worked on several 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 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-graduatelevel courses on operating systems, computer communication networks, and performance evaluation of telecommunication systems. 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 Communications 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 institutions. He is a member of the IEEE Communications Society. He has participated in the technical program committees and chairing sessions of several conferences, including 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. Volume 82, Number 6 SIMULATION 397