Real-Time QoS DiffServ Gateway Implementation for Satellite IP ...

Real-Time QoS DiffServ Gateway Implementation for Satellite IP Networks Luca Simone Ronga † , Romano Fantacci ‡ , Tommaso Pecorella † Francesco Volpi ‡ †

CNIT Florence Unit University of Florence Via di Santa Marta 3, 50139 - Florence, Italy

Abstract— IP satellite networks are gaining a considerable interest and this is mainly due to their ability to deliver high bandwidth services to nation-wide areas. Some difficulties exist, however, to implement IP based transport mechanisms on geo-stationary satellite networks. TCP based protocols performance are heavily affected by the large delay-bandwidth product on GEO satellites and by the coexistence of UDP and TCP on the same limited resource. In the literature several methods have been proposed to provide quality of service control on IP networks. The most scalable approach is the Differentiated Services (DS). This paper proposes a real-time implementation of a satellite system, mapping the DS entities on software elements on a Linux platform. A detailed analysis has been computed to verify the performance of the RED/DS method with real traffic flows and some optimization are suggested.

I. I NTRODUCTION IP satellite networks are gaining a considerable interest and this is mainly due to their ability to deliver high bandwidth services to nation-wide areas. The market is rapidly moving to high speed multimedia services and the number of users served by Internet is increasing exponentially. Internet2, the global Internet upgrade [1], will probably be able to satisfy the requirements but its deployment will probably occur gradually. Satellites are the perfect candidates to provide high quality IP services in the development phase of fast terrestrial networks. Some difficulties exist, however, to implement IP based transport mechanisms on geostationary satellite networks. TCP based protocols are affected by the large delay-bandwidth product, a typical scenario for GEO satellites delivering large bandwidth services [2]. Also the coexistence of UDP and TCP traffic causes performance degradation; the dependence of TCP performance from UPD makes it very difficult to provide a suitable pricing method for both. In the literature several methods have been proposed to provide quality of service control on IP networks. The most scalable approach is the Differentiated Services (DS) [3]. With the DS mechanism, the IP packet is classified at the boundary of the network and an appropriate mark, the codepoint, is inserted in the header. In the core network, the codepoint is used to determine the so called Per-Hop Behavior (PBH) that maps a global delivering requirement to a local link transmission treatment. The DS approach is considered for use on satellite networks for three main reasons: • Satellites are designed to serve aggregate traffic so a scalable QoS approach is to prefer for efficiency and implementation reasons. • Space segments often represent only a part of the larger service network which is made also of terrestrial links. The Satellite DS provision simplifies the integration with the terrestrial DS since only the PHB is adapted to the satellite segment. • The limited computational capacity on-board promotes the use of QoS methods whose complexity is maintained at the edges of the networks, like DS.

‡

DET Department - University of Florence Via di Santa Marta 3, 50139 - Florence, Italy

Fig. 1. The emulated system

Several methodologies have been proposed to implement DS on satellite networks. In [4] the authors propose a scheduling method based on Random Early Detection, where excess packets are randomly discarded from the gateway to prevent congestion and provide the committed service levels. The discard probability for a packet is related to the profile status of class of users the packet belongs to, and it is differentiated for TCP and UDP traffic. Based on this approach, this paper proposes a real-time implementation of the satellite system, mapping the DS entities on the available software elements on a Linux platform. A detailed analysis has been computed to verify the performance of the RED/DS method with real traffic flows and some optimization and modification to the original methods are suggested. In the next section is described the considered satellite environment. The DS implementation is detailed in Section III while the results of measurement campaigns are described in Section IV. Section V contains some concluding remarks. II. T HE S ATELLITE E NVIRONMENT The considered system is composed by the elements in Fig. 1. We can see: • 10 virtual sources: 9 TCP aggregates (each characterized by 5 single TCP flows) plus a single UDP source which represents the aggregate of several UDP flows. The UDP source produces a constant traffic of 1.28 Mbps. • The two earth gateways where the traffic is processed before the transmission to the satellite. • The satellite link with a total bandwidth of 1.5 Mbps, characterized by an error free channel whose propagation delay is 250 ms. The target is to provide a mechanism that: • guarantees a minimum bandwidth among the 10 aggregates, • distribute equally the excess bandwidth among the flows. The satellite system is implemented with three hosts interconnected by dedicated LANs, as shown in Fig. 2. The first host of Fig. 2 is responsible for the traffic generation, the DS marking and the delay of the reverse channel (ACKs

TABLE I AF PHB C LASSES

Low Discard Prob. Mid Discard Prob. High Discard Prob.

Fig. 2. The testbed architecture

from the TCP destinations). The central host is operating the Assured Forwarding PHB for the selected scheduling, as well as a virtual bandwidth limitation to 1.5 Mbps. The last host implements the traffic destinations as well as the forward propagation delay of the satellite link. III. T HE I MPLEMENTED Q O S A RCHITECTURE The key elements that have influence on the performances of a IP satellite networks are the bandwidth management, queue management, the various traffic types and their treatment across the network nodes. In the considered environment we focus on a system able to guarantee a minimum rate to each aggregate of traffic. The excess bandwidth is then fairly redistributed among aggregates, even in the case of coexistence of UDP and TCP traffic. To obtain the target, proper queuing and scheduling strategies are to be implemented. In the literature there are two main approaches: the Tail Drop and the Random Early Detection [5]. The former discards all the incoming packet of a traffic class if the related FIFO queue is full. The latter discards the packets with an increasing probability as the FIFO queue gets full. In our implementatation we chose the latter approach which permits, among other things, a fine tuning of the behaviour by selecting appropriate parameters, as shown below. To achieve a fair balancing of performance for UDP and TCP traffic, the aggregates have been differentiated based on transport protocol they use. So TCP and UDP have their own classification and treatment in the gateway node. As a matter of facts a common processing is known to limit dramatically flow control based transport, i.e. TCP, when in the link are present UDP aggregates [6], [7], [8]. A. RED - Random Early Detection RED has been designed to allow a fair treatment of aggregates of TCP flows [5], [9]. When the aggregate is constituted by several TCP flows, the RED algorithm is able to distribute equally the bandwidth among the single flows, even in presence of various rates of sources. This is achieved by limiting the most aggressive flows by dropping the related packets with a greater probability. This drop activates the flow control mechanisms of TCP inducing a source rate reduction. Our system employs RED by processing TCP classified aggregates on a queue, and UDP and unclassified traffic on another one. For each queue, the occupancy is evaluated by an exponential moving average. The computed occupancy value, say avg, is compared with two thresholds, say minth and maxth . When a

Class 1

Class 2

Class 3

Class 4

AF11 AF12 AF13

AF21 AF22 AF23

AF31 AF32 AF33

AF41 AF42 AF43

new packet arrives and avg < minth the packet is accepted. If minth < avg < maxth the packet is discarded with a probability pa , function of avg. If avg > maxth the packet is discarded. If we define the quantity pb : pb = maxp

avg − minth maxth − minth

(1)

where maxp is a system parameter that represents the peak discard probability. The final discarding probability, function of avg, the thresholds and maxp is given by: pa =

pb 1 − count · pb

(2)

where count is the number of packets arrived since the last drop. avg is computed with an exponential moving average, defined by: avg (i) ← (1 − wq )avg (i−1) + wq q. (3) where 1/wq is the forgetting factor of the moving average. B. PHB Assured Forwarding IETF currently defines three main forwarding policies as PHB. The PHB Expedited Forwarding (PHB-EF), the PHB Assured Forwarding (PHB-AF) and Best Effort (PHB-BE). The PHB-EF is mainly adopted for tightly constrained traffic, like real time media streams. BE is the PHB used for unclassified traffic, as in the current Internet. The PHB-AF is the policy suggested for non real-time QoS enabled traffic. The Assured Forwarding, defined in [10], is divided into 4 independent forwarding sub-classes. In each class, the packets can receive 4 different discarding probability. The table I shows the recommended AF code-points and their discarding probabilities. In the table a packed belonging to class i with discarding priority j is classified with the DiffServ code-point (DSCP) AFi,j . In the rest of the document the packets with low discard probability will be called ”green” packets, those with medium discard probabilities ”yellow” ones and those with high discard probability ”red”. In the emulated testbed of fig. 2 the traffic is generated and all the packets receive a DS classification based on the following ruleset: 1. Each aggregate is assigned a ”green” rate, i.e. the minimum assured rate that will correspond to the minimum amount of guaranteed bandwidth. A Token Bucket [3] mechanism is employed to determine if a packet belongs to the ”green” rate of its aggregate and, in this case, its DSCP is marked with the ”AF11 ” label (Green). 2. Excess traffic is first classified with its transport protocol (TCP or UDP). UDP excess traffic is assigned a high discard priority with the DSCP set to ”AF13 ”, the ”red” one. Excess TCP

Virtual queues

avg

forward RED

discard

Fig. 3. DS Marker Implementation Fig. 5. GRED with virtual queues

Fig. 4. DS Router Implementation

traffic whose rate is greater than the ”green” rate but less than the ”yellow” plus the ”green” rate, is marked as ”yellow” (AF12 ). All the remaining TCP traffic is colored as ”red” (AF13 ). C. DS Conditioner The mentioned DS marking is obtained by the functional elements shown in fig. 3. The Linux implementation of DS is composed of Qdisc objects that have the function of queues, containers for others Qdisc and schedulers. The implemented DS marker performs the following functions: • the outer Qdisc extracts the DSCP from the incoming packet, • the u32 multi-field classifier assigns the proper class to the packet by operating a priority conditioned distribution of the incoming packets into three different FIFO queues. The packets that will satisfy the ”green” rate token bucket acceptance rule will be placed in the ”green” FIFO, and so on. • the packet served by the outer Qdisc and its DSCP is set accordingly to its class • the packet is finally released D. DS Router The middle host in fig. 2 operates the functions of the DS satellite gateway. It receives packets from the terrestrial side of the gateway and forward them through the satellite link in accordance to the DS classification. The DS router implementation is represented in figure 4. The outer Qdisc (dsmark) extracts the DSCP from the incoming packet and its value is saved in the temporary data structure tc->index. The packet is transferred to a Class Based Queuing Qdisc (Qdisc CBQ) which adapt the overall traffic to the hard-limited satellite bandwidth of 1.5 Mbps.

Inside the CBQ Qdisc is present an inner Qdisc with a Generalized RED scheduling which receives all the incoming traffic. This is actually the core of the proposed implementation. The GRED Scheduling implements three virtual RED discard policies, one for each class color of the incoming packets. The virtual queues RED implementation obtained in the testbed is depicted in fig. 5. Each incoming packet acts as if it were placed in a queue corresponding to its discard class. The length of this virtual queue is computed and, based on the avg, minth , maxth and maxp parameters for its class, the probability of discard is produced. The packet is then discarded or accepted for transmission accordingly. Each virtual queue has its own set of discard parameters. IV. F IELD T RIALS AND R ESULTS Several field experiments have been conducted with the emulation testbed described in the previous sections. The flexibility of the architecture allows a large number of variations of the operating parameters in the satellite systems. For editorial reasons only the most significant results are commented in this paper. The various system parameters can be summarized in the following list: green rate, this is the average granted bandwidth for each specific aggregate subject to QoS. yellow rate (for TCP flows only), when the rate of a flow is between ”green rate” and ”green + yellow rate” the packets of that flow are marked as ”yellow”. If the yellow rate is ”0” the TCP and UDP traffic are not distinguished by the QoS mechanism. buffer sizes for the green and yellow token bucket, which have influence on the reactivity of the QoS mechanism. The larger is the the buffer, the slower is the response to fast changes in traffic rates. maxp minth e maxth , for each of the three RED discarding classes. For each traffic aggregate a throughput measurement has been taken at the end of the transmission chain. The throughput is the total traffic at destination for UDP flows and the acknowledged traffic for TCP. The measure is split into ”green” and ”out-ofgreen” (i.e. ”yellow and red”) throughput. As an additional index of performance we consider also the fairness index (see

Fig. 7. Performance of DS RED satellite gateway

Fig. 6. Performance of a FIFO IP satellite gateway

[4]),defined by: P10 ( i=1 xi )2 F airness Index = , P10 10 · i=1 (x2i )

(4)

where xi is the ”out-of-green” rate for the i-th aggregate. The first chart in figure 6 shows the effect of the sharing of a limited bandwidth between UDP and TCP aggregates without QoS support. The UDP throughput dominates the link as expected. When the QoS support is enabled as described in the previous sections, the throughput of the aggregates are reported in figures 7 and 8 for ”green rates” of 1.6 kbps and 12.8 kbps respectively. The other system parameters are shown in table II. In both the operating conditions is shown a good balance between TCP and UDP traffic. The fairness index, however, is smaller in the case of a larger green rate. This is confirmed by the ”out-of-green” throughput analysis reported in the figures 9 and 10 for ”green rates” of 1.6 kbps and 12.8 kbps respectively. Here the total ”green” throughput is shown aside, while the excess throughput for each aggregate is detailed. In the case of a small green rate (1.6 kbps), also the excess traffic is equally distributed among the sources. When the green rate represents a considerable fraction of the overall available bandwidth, the proposed balancing mechanism is less effective. We consider, however, that when the excess traffic is small compared to the total available bandwidth, the need for a balancing method is less important since the ”green rate” already provides a good way to distribute the resource and to protect TCP flows.

Fig. 8.

Fig. 9.

V. C ONCLUDING R EMARKS In this paper we propose a real-time architecture for the provision of Differentiated Services on IP satellite network. The QoS mechanism is based on RED policy and is designed to protect TCP flows against UDP aggregates when they share the same bandwidth on a limited resource. The key elements in the emulated network have been implemented on the Linux platform and an extensive performance evaluation and a parameters tuning have been conducted. The system provides a good distributions of the available bandwidth among all the protected aggregates, specially for TCP based flows. The DS architecture of the satellite gateway is simple to implement and the parameters

Fig. 10.

TABLE II E MULATION PARAMETERS

Green Rate (bps) Green Bucket (bytes) Yellow Rate (bps) Yellow Rate (bytes) Green minth Green maxth Green maxp Yellow minth Yellow maxth Yellow maxp Red minth Red maxth Red maxp

1600 4672 19056 18688 23040 34560 0.5 11520 23040 0.5 1024 2880 1.0

12800 4672 6611 18688 23040 34560 0.5 11520 23040 0.5 1024 2880 1.0

tuning does not affect the network size, resulting in a scalable and flexible architecture. ACKNOWLEDGMENTS The authors wish to thank Dr. Mario Marchese and Eng. Davide Adami, who contributed with comments and suggestions to the development of this work. R EFERENCES [1] [2]

The Internet 2 consortium, “Internet 2,” http://www.internet2.org. M. Allman, C. Hayes, H. Kruse, and S. Ostermann, “TCP Performance over Satellite Links,” 5th International Conference on Telecommunication Systems, Agosto 1997. [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Services,” RFC 2475, Dicembre 1998. [4] A. Durresi, S. Kota, M. Goyal, R. Jain, and V. Bharani, “Achieving QoS for TCP traffic in Satellite Networks with Differentiated Services,” Proc. Journal of Space Communications, vol. 17, no. 1-3, pp. 125–136, 2001. [5] Sally Floyd and Van Jacobson, “Random Early Detection Gateways for Congestion Avoidance,” IEEE/ACM Transactions on Networking, Agosto 1993. [6] Nasir Ghani and Sudhir Dixit, “TCP/IP Enhancements for Satellite Networks,” IEEE Communications Magazine, vol. 37, no. 7, pp. 64–72, Luglio 1999. [7] C. Barakat, E. Altman, and W. Dabbous, “On TCP Performance in a Heterogeneous Network: A Survey,” IEEE Communications Magazine, vol. 38, no. 1, pp. 40–46, Gennaio 2000. [8] T. V. Lakshman and U. Madhow, “The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss,” IEEE/ACM Transactions on Networking, 1997. [9] D. Lin and R Morris, “Dynamics of Random Early Detection,” ACM SIGCOMM, Settembre 1997. [10] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, “Assured Forwarding PHB Group,” RFC 2597, Giugno 1999.