Some Simulation Results About Shaped TCP ... - CiteSeerX

Some Simulation Results About Shaped TCP Connections in ATM Networks

3

M.Ajmone Marsany, A.Biancoz, R.Lo Cignoy, M.Munafoy y Dipartimento di Elettronica, Politecnico di Torino, z Dipartimento di Sistemi di Produzione ed Economia dell'Azienda, Corso Duca degli Abruzzi 24, 10129 Torino { Italy fajmone,bianco,locigno,[email protected]

We discuss simulation results concerning the performance of the TCP protocol when running over high-speed ATM networks. Two network topologies are considered: a simple network topology, comprising just two ATM switches and one ATM channel supporting 3 unidirectional TCP connections, and a candidate Italian ATM network topology compirisng 9 ATM switches and supporting 6 unidirectional TCP connections. In all simulation scenarios the TCP trac is mixed with some background trac whose level is taken as a variable parameter. Both the background trac and the TCP trac are either unshaped, or shaped according to the GCRA algorithm. The eect of the background trac on the TCP protocol performance is discussed varying the buering capacity within nodes as well as the peak bit rate that each TCP connection is allowed to use. Numerical results clearly show that shaping the TCP trac signi cantly improves both the goodput and the eciency of the TCP connections.

1

Introduction

The evolution of the ATM standards and products towards the LAN market clearly indicates that the rst ATM networks will be mainly used to transport data trac for business applications; however, also in the long run, data trac is expected to remain a relevant part of the load in ATM networks. It is thus very important that higher-level protocols used for the implementation of data applications be carefully investigated with respect to their adaptability to the ATM environment. TCP is now the de facto standard transport protocol for data applications in the LAN, MAN and WAN areas. Many experts believe that TCP for a long time to come will also be the most frequently used transport protocol in the ATM environment, even if it has been recognized that TCP is not speci cally tailored to high-speed applications. Some studies of the behaviour and performance of TCP when used in an ATM network have already appeared [1, 2, 3, 4, 5, 6]. Our work concentrates on the eect that the heterogeneous trac present in the network, that we call background trac, may have on the TCP performance. The importance of the presence of background trac goes beyond the reduction of the bandwidth available to TCP, since background trac interferes with the TCP behavior by altering the probability of cell losses within node buers. Moreover, we also investigate the in uence of \trac shaping" on the TCP performance. Shaping the TCP trac at the network ingress may be a reasonable approach to allow the network to control the TCP source rate without requiring a substantial rewriting of the TCP code itself. Note however that a negotiation phase between the user and the network is necessary in order to agree on a given peak cell transmission rate; this rate will limit the throughput of the TCP connection, even if the throughput achievable by the TCP window mechanism could be higher. The results presented in this paper are obtained via simulation with CLASS, an ATM network simulator recently developed at Politecnico di Torino [7, 8]. To obtain a model for the TCP protocol, we adapted the ocially distributed C code of the BSD 4.3-reno release [9], without considering the delayed and selective ACK otpions (for details see [5]). 3

This work was supported in part by a research contract between Politecnico di Torino and CSELT (Centro Studi e

Laboratori Telecomunicazioni), and in part by the Italian Ministry for University and Research.

16/1

The paper is organized as follows. Section 2 is initially devoted to the description of the considered network topologies, and then to the illustration and discussion of the simulation results. We rst present a set of simulation results obtained considering three TCP connections sharing one ATM link in a two-node ATM network. This very simple network scenario allows us to understand in detail some aspects of the TCP behavior and performance in ATM networks. Then, a more complex network is used, based on the topology of the candidate Italian ATM network. In this more complex situation it is much harder to fully understand the dynamics of each TCP connection, but some useful insights can still be gained from this more realistic scenario. Finally, Section 3 concludes the paper. To avoid the use of the term packet, that may lead to confusion, throughout the paper we use the term segment to identify the TCP data unit, and the term message for the data units exchanged by the background trac sources and destinations. TCP segments are divided into cells by the AAL 5 sublayer before accessing the ATM service, while the AAL 3/4 sublayer is used for the messages of the background trac.

2

Performance results

In all the simulation scenarios that we considered, TCP connections are supposed to operate in sustained overload, performing a very long le transfer: segments are always ready at the transmitter when an ACK is received. The size of the buers at the TCP transmitters is set to a value that avoids any loss at the source during the fragmentation process of a TCP segment into ATM cells. The TCP receivers are assumed to be fast enough and to have enough buer space so as to avoid losses. The maximum window size is set to a value that allows a single TCP transmitter to obtain the full available bandwidth on the link. It is supposed that the TCP protocol always transmits segments of 9180 bytes, the suggested maximum segment size for TCP over ATM. The background trac messages are generated according to a Poisson process, with a truncated geometric message length distribution with mean equal to 20 cells and maximum length 200 cells. The burstiness of both the TCP connections and the background trac can be controlled with a shaping device that operates according to an adaptation of the GCRA (Generic Cell Rate Algorithm) recommended by ITU-T for trac policing in ATM networks [10]. A GCRA shaper is based on the control of the cell interdeparture time by delaying cells that are scheduled for transmission too early. The basic parameters of the GCRA shaper are the bandwidth allocation factor , which is the amount of bandwidth allocated to the connection relative to its mean bandwidth, and the cell delay variation tolerance which is the amount of time that a cell is allowed to \accelerate" with respect to its expected arrival time. When the background trac is shaped, we assign to each connection = 1:2 and = 0 in the case of the simple 2-node network, while in the Italian network the bandwidth allocation factor is = 1:5 for coherence with previous studies on this network [7, 11]. Numerical results are presented as curves referring to two performance indices:

goodput, at the TCP receivers, obtained considering the received data, but discarding all the faulty and the retransmitted segments;

the useful throughput, called the

eciency of the TCP connections, i.e., the ratio between the goodput and the total oered

load of TCP connections.

Both the background trac load and the TCP goodput are expressed in Mbit/s of user data. Thus, in order to obtain the link utilization, the background load must be multiplied by a factor 53/44 (we use AAL3/4 for the background trac), while the TCP goodput must be divided by the eciency and multiplied by a factor 53/48 (AAL5 assumed). Simulations were run either until the receiver throughput reached a 98% precision with 95% con dence, or stopped after 140 s of simulated time. However, the 2-node network with high background trac was so overloaded that one of the TCP connections was forced to close by the backo mechanism. A great attention must be paid when interpreting these results, since this behavior indicates that the network is very loaded and the TCP connections do not reach a steady-state condition. In particular,

Background Traffic Tx1

Tx2

Tx3

Rx1

L1

L0

L2 L3

Rx2

Rx3

Background Traffic

Figure 1: The simulated ATM network the reliability of most of the simulation runs with a background trac load equal to 100 Mbit/s is questionable. 2.1

The two-node network

We rst consider a very simple network, sketched in Fig. 1, comprising only two ATM switches. The data rate on each channel is 150 Mbit/s, and channel L0, linking the two ATM switches, is the system bottleneck. Three unidirectional TCP connections share the network resources with a variable amount of background trac. The performance of this very simple ATM network was studied in detail in [5] as a function of three variables: the TCP connection lenght (the network span), the background trac load and trac characteristics, and the TCP trac shaping parameters. We only report here some gures that help in understanding the other results and also serve as a reference when considering more complex scenarios. The results presented in Fig. 2, are obtained when all the links L0; L1; L2; L3 in Fig. 1 have length 500 km, while the links from the second ATM switch to the TCP receivers are assumed to have negligible length. The TCP connection length is thus 1000 km. The results are presented as a function of the background trac load, for two values of the node buer size in front of the congested link L0 : 1000 and 5000 cells, with the background trac shaped. As expected, when no shaping is performed on the TCP trac (dotted lines with square markers), the TCP goodput steadily decreases with increasing background trac; on the contrary, an increase in the node buer size results in an increase of the TCP goodput, even if this increase is not very signi cant, as can be observed comparing the lines with the square markers in the left-hand side gures. The results when the trac on TCP connections is shaped are presented on the same charts with the plus and diamond markers for the cases of 50 and 15 Mbit/s shaping, respectively, assuming a cell delay variation tolerance = 0. These shaping values correspond to 1/3 and 1/10 of the bottleneck link capacity. The results are rather interesting, showing that smoothing the burstiness of the trac oered to the network allows TCP connections to better exploit the available resources. In particular, when a 50 Mbit/s shaping is enforced on TCP connections and no background trac is present, the TCP connections completely saturate the link capacity, since they grab 149.4 out of 150 available Mbit/s, while without shaping the goodput does not exceed 83 Mbit/s, for 5000-cell node buers. In any case, the goodput achieved with a 50 Mbit/s shaping is always greater than the unshaped goodput, regardless of the node buer size and the background load. The situation is slightly dierent when we analyze the curves with 15 Mbit/s shaping. In this case the TCP goodput is limited by the shaping function, not by the window mechanism, and it remains constant until the background load is increased to 75 Mbit/s. In this case, for high background trac load, the goodput is greater than the one obtained in the case without shaping and with 50 Mbit/s shaping. It is interesting to notice that in the case of 100 Mbit/s background trac load, when the network is clearly overloaded, the performance of the TCP connections is basically independent from the shaping function.

Buffers 1000 cells - Length 1000 km


50.0 Shaping 15 Mbit/s Shaping 50 Mbit/s No Shaping

45.0

0.80

35.0 30.0

Efficiency

Receiver Goodput [Mbit/s]

40.0

1.00

25.0 20.0

0.60

0.40

15.0 10.0

Shaping 15 Mbit/s Shaping 50 Mbit/s No Shaping

0.20

5.0 0.0

0.00 0

25 50 75 Background Traffic [Mbit/s]

100

0



100


50.0 Shaping 15 Mbit/s Shaping 50 Mbit/s No shaping

45.0

0.80

35.0 30.0

Efficiency


40.0

1.00

25.0 20.0

0.60

0.40

15.0 10.0

Shaping 15 Mbit/s Shaping 50 Mbit/s No shaping

0.20

5.0 0.0

0.00 0


100

0


100

Figure 2: Average goodput and eciency of the TCP connections for the simulated scenario with connection 1000 km long as a function of the node buer size and the background load; the background trac is shaped More insight can be achieved by looking at the eciency of the TCP protocol (the charts on the right-hand side of Fig. 2). These curves clearly show that as soon as the total trac oered to the network exceeds the bottleneck link capacity, the eciency of the TCP protocol becomes very poor, dropping to 0.5 or even less. Moreover, the more bursty is the trac, the poorer is the eciency. This result is also con rmed by simulation runs without shaping of the background trac, where the TCP performance (not reported in the graphs) is even poorer. Indeed, the only acceptable, even amazingly good, situation is the one with 15 Mbit/s shaping, whose eciency remains equal to 1 (no segment loss was recorded) up to a background trac load equal to 75 Mbit/s; when the background load reaches 100 Mbit/s, the network is, as already stated, overloaded in all cases, and its performance becomes independent from the shaping function. It is interesting to notice the fact that with node buer size equal to 1000 cells, the eciency of TCP without shaping and with 50 Mbit/s shaping seems to increase slightly for background trac load 50 and 75 Mbit/s after dropping to about 0.5 for background trac load 50 Mbit/s. This phenomenon might be due to statistical uctuations, but we believe that it is more probably due to phasing phenomena like those examined in [1, 4]. The second set of results that we discuss considers TCP connections with dierent lengths. This situation may be very common in reality, and it deserves investigation, since the TCP control mechanism is known to be biased against longer connections. In this scenario the goodput of each connection is separately taken into account and plotted. With respect to the simulation scenario presented in Fig. 1, the bottleneck link length L0 is set to 500 km, while the lengths of the links L1 , L2 and L3 are set respectively to 5, 50 and 500 km, resulting in connections whose lengths are 505, 550 and 1000 km. Fig. 3 reports the results for buer size equal to 5000 cells, when the TCP connections are either unshaped or shaped at 50 Mbit/s. The shaping at 15 Mbit/s is not reported for the sake of

Buff. 5000 cells - No shaping - L0=500

Buff. 5000 cells - No shaping - L0=500

50.0 connection 5km connection 50km connection 500km

45.0

0.80

35.0 30.0

Efficiency


40.0

1.00

25.0 20.0

0.60

0.40

15.0 10.0

connection 5km connection 50km connection 500km

0.20

5.0 0.0

0.00 0


100

0

Buff. 5000 cells - shaping 50 Mbit/s - L0=500


100

Buff. 5000 cells - shaping 50 Mbit/s - L0=500

50.0 connection 5km connection 50km connection 500km

45.0

0.80

35.0 30.0

Efficiency


40.0

1.00

25.0 20.0

0.60

0.40

15.0 10.0

connection 5km connection 50km connection 500km

0.20

5.0 0.0

0.00 0


100

0


100

Figure 3: Goodput and eciency of the TCP connections for the simulated scenario with connections 1000, 550 and 505 km long as a function of the shaped background load with buer size equal to 5000 brevity since all of the connections obtain exactly the same goodput. When the TCP connections are unshaped, it can be noticed that the goodput obtained by the connections is inversely proportional to the connection length, as expected, since the TCP throughput is roughly inversely proportional to the round trip delay. The unfair behavior is clear, and it can be remedied by adopting a 50 Mbit/s shaping. In this case the goodput dierence between the connections of length 505 and 550 km is negligible, while the connection with length 1000 km still gets a lower bandwidth, but with low background trac loads this dierence becomes less signi cant. It is interesting to notice that the eciency of the connection is independent from the connection length, also if no shaping is performed on the connections. This means that the losses due to buer over ow are roughly proportional to the bandwidth grabbed by the connection. Let us now consider what happens if we draw the results as a function of the bandwidth assigned to each TCP connection. In this case, with reference to Fig. 1, we set the links lengths to 50 km, thus simulating 100 km connections. The size of the buer in front of the congested link L0 is set to 1000 cells. Fig. 4 reports the results obtained in this scenario. Each graph contains two pairs of curves: the rst pair is obtained with a background trac level of 45 Mbit/s, while the second one is obtained with background trac level of 15 Mbit/s. Curves within each pair refer either to the case of shaped background trac or to the case of unshaped background trac. The dierence between curves obtained by shaping the background trac and those obtained by letting the background trac unshaped is not signi cant since the buer is big enough to accomodate the background trac bursts. All of the curves show the following behaviour: if the assigned bandwidth is such that the link is not overloaded (assigned bandwidth equal to 30 Mbit/s with 45 Mbit/s background and 37.5 Mbit/s with 15 Mbit/s background) the TCP connections eciency sticks to one and hence the average goodput increases linearly. As soon as the link get overloaded the TCP



50.0 Unshaped Background - 45 Mbit/s Shaped Background - 45 Mbit/s Unshaped Background - 15 Mbit/s Shaped Background - 15 Mbit/s

45.0

1.00

35.0 30.0

Efficiency


40.0

Unshaped Background - 45 Mbit/s Shaped Background - 45 Mbit/s Unshaped Background - 15 Mbit/s Shaped Background - 15 Mbit/s

1.20

25.0 20.0

0.80 0.60 0.40

15.0 10.0

0.20 5.0 0.0

0.00 10

20

30 40 50 60 Assigned bandwidth [Mbit/s]

70

80

10

20

30 40 50 60 Assigned bandwidth [Mbit/s]

70

80

Figure 4: Goodput and eciency of the TCP connections for the single bottleneck scenario with 3 connections 100 km long as a function of the assigned bandwidth with dierent 1000-cell buers, background load set to 25 or 75 Mbit/s either shaped or not TCP Conn Mi-Ro To-Fi Ve-To Ro-Ba Ba-Pa Pa-Ba

0.8 Gbit/s 1st 2nd 3rd 0.41 0.294 0.114 0.11 0.072 0.30 0.25 0.06 0.06 0.028 0.028 0.06

1.0 Gbit/s 1st 2nd 3rd 0.51 0.367 0.143 0.13 0.090 0.377 0.32 0.074 0.074 0.035 0.035 0.074

1.2 Gbit/s 1st 2nd 3rd 0.61 0.44 0.165 0.15 0.098 0.43 0.38 0.088 0.088 0.042 0.042 0.088

Table 1: Measured load of the background trac, measured as a percentage of the link capacity, on the links crossed by the TCP connections. eciency drops around 0.5 and the goodput decreases. This shows that, at least in such a simple scenario, it is possible to assign to TCP connections an optimal transmission bandwith as a function of the available bandwidth on the link. 2.2

The Italian network

The candidate Italian network topology comprises nine ATM switches, located in the major Italian cities, and is shown in Fig. 5; the buering capacity at all nodes is set to 100 cells per port, and the user transmission buer sizes are set to quite large values in order to avoid losses at the source. Six unidirectional TCP connections can be identi ed: Mi-Ro, To-Fi, Ve-To, Ro-Ba, Ba-Pa and Pa-Ba. The total amount of background trac in the network is equal to 0.8, 1.0 and 1.2 Gbit/s, and the trac distribution is highly asymmetric, the network having essentially two hot spots in Rome and Milan. We do not report the complete workload distribution for the backgrond trac for sake of brevity, but it can be found in [7, 11]; Table 1 presents the load, measured as the percentage of the link capacity, of all the links crossed by the six TCP connections. All the TCP connections have a window size that allows a transmission speed up to 150 Mbit/s. The Mi-Ro TCP connection, is carried on a link with a lot of available capacity, since 60%, 50% and 40% of a 600 Mbit/s channel is available for it, respectively. The Ba-Pa and Pa-Ba connections are running on very lightly loaded links, while the three TCP connections, To-Fi, Ve-To and Ro-Ba run over 150 Mbit/s channels whose loads could signi cantly in uence the TCP performances. We present results for either shaped or unshaped background trac. Simulations were run considering four possible scenarios for all the TCP connections: unshaped TCP connections, TCP connections

MI VE TO

GE

BO FI

150 Mbit/s links 600 Mbit/s links

TO = Turin MI = Milan VE = Venice GE = Genua BO = Bologna FI = Florence RO = Rome NA = Neaples BA = Bari PA = Palermo

RO

NODES NA

USERS TCP SENDER

BA

TCP RECEIVER

PA

Figure 5: Topology of the Italian network shaped at a link speed of 25Mbit/s, 37.5Mbit/s and 50Mbit/s, which means that the TCP goodput can be at most 22.5, 33.8 and 45.1 Mbit/s respectively. Figures 6 and 7 present the goodput and eciency for the six TCP connections, as a function of the global background network load; curves refer to TCP connections shaped either at 22.5 Mbit/s, or at 33.8 Mbit/s, or at 45.1 Mbit/s, or unshaped, with background trac either shaped or unshaped. First we consider the results when no shaping is enforced on the TCP connections. If the background trac is shaped, the Mi-Ro connection runs at full speed, without any loss; but if the background trac is not shaped, the throughput decreases signi cantly, reaching values as low as 28 Mbit/s, even if a huge amount of bandwidth is available for the TCP connection on that link. A similar eect can be observed for both the Pa-Ba and Ba-Pa connections, even if the performance dierence is not so signi cant. The To-Fi, Ve-To and Ro-Ba connections are in a very critical situation; even if they obtain a goodput that would make happy anybody on today's networks, their eciency is really low. This means that an unnecessary amount of retransmitted segments is sent through the network, signi cantly decreasing the background trac throughput. Moreover, the TCP protocol is forced to work in a condition of continuous retransmissions; a slight increase in the link load would force TCP to continuosly backo and nally close the connection. In these conditions, shaping the background trac is not enough to obtain reasonable goodput. If the impact of shaping the background trac is important, even more impressive is the bene cial eect obtained by shaping the TCP connections. Clearly, a shaping function limits the TCP connections that would have otherwise a higher throughput, as for example for the Mi-Ro connection. However, the amazing results concern the suering TCP connections, that is those labelled To-Fi, VeTo and Ro-Ba. All these connections obtain a signi cant increase in both their goodput and eciency with respect to the case when no shaping is enforced. Most of the connections obtain a throughput close to the maximum allowed by the shaping function, especially when also the background trac is shaped. As a conclusion, shaping the background trac can increase the goodput and eciency of TCP connections. The eect of shaping the TCP connections themselves is amazingly good; not only an eciency close to 1 can be obtained, but the increase in goodput can be really impressive. Obviously,

Connection from Milan to Rome

Connection from Milan to Rome

140.0

1.00 Shaped Background Unshaped Background No Shaping 22.5 Mbit/s 33.8 Mbit/s 45.1 Mbit/s

100.0 80.0

0.80 Efficiency


120.0

60.0


0.40

40.0 0.20 20.0 0.0 0.7

0.8

0.9 1 1.1 1.2 1.3 1.4 Global Background Load [Gbit/s]

0.00 0.7

1.5

0.8

Connection from Bari to Palermo


1.5

Connection from Bari to Palermo

50.0 1.00

45.0

0.80

35.0 30.0

Efficiency


40.0

25.0 20.0

Shaped Background Unshaped Background No Shaping 22.5 Mbit/s 33.8 Mbit/s 45.1 Mbit/s

0.40

15.0


10.0 5.0 0.0 0.7

0.60

0.8


0.20

0.00 0.7

1.5

0.8

Connection from Palermo to Bari


1.5

Connection from Palermo to Bari

50.0 1.00

45.0

0.80

35.0 30.0

Efficiency


40.0

25.0 20.0


0.40

15.0


10.0 5.0 0.0 0.7

0.60

0.8


0.20

1.5

0.00 0.7

0.8


1.5

Figure 6: Average goodput and eciency of the TCP connections for the simulated scenario with connection 1000 km long as a function of the node buer size and the background load

Connection from Rome to Bari

Connection from Rome to Bari

50.0 1.00


35.0 30.0

0.80 Efficiency


40.0

25.0 20.0


0.60

0.40

15.0 10.0

0.20

5.0 0.0 0.7

0.8


0.00 0.7

1.5

0.8

Connection from Turin to Florence


1.5

Connection from Turin to Florence

50.0 1.00


35.0 30.0

0.80 Efficiency


40.0

25.0 20.0

0.60


0.40

15.0 10.0

0.20

5.0 0.0 0.7

0.8


0.00 0.7

1.5

0.8

Connection from Venice to Turin


1.5

Connection from Venice to Turin

50.0 1.00


35.0 30.0

0.80 Efficiency


40.0

25.0 20.0

0.60


0.40

15.0 10.0

0.20

5.0 0.0 0.7

0.8


1.5

0.00 0.7

0.8


1.5

Figure 7: Average goodput and eciency of the TCP connections for the simulated scenario with connection 1000 km long as a function of the node buer size and the background load

also the background trac bene ts from the TCP trac shaping. However, a too restrictive shaping could force TCP to run at a speed slower than allowed by the network load; thus the problem of selecting the optimal value for the shaping function has to be carefully studied. The above results suggest that adaptive shaping algorithms for TCP connections running over ATM networks could be really valuable assets to obtain high eciency and network utilization.

3

Conclusions

The performance of the TCP protocol when running over a simple ATM network was studied through simulation, in two network scenarios. We took as performance parameter the background trac load, the buering capacity in the ATM switches, the trac shaping parameters of both TCP and background trac and the length of the TCP connections. Numerical results clearly showed that shaping the trac on the TCP connections greatly improves the TCP performance. Shaping can be applied with no modi cation of the TCP protocol itself, but it implies the negotiation of a trac contract between the network and the TCP protocol entities at connection setup. The shaping of the oered load seems a good means to enforce a certain degree of fairness among connections with dierent lengths.

References [1] A. Romanow, S. Floyd, \Dynamics of TCP Trac over ATM Networks", ACM London UK, September 1994

SIGCOMM'94

,

[2] T.V.Lakshman, U.Madhow \Performance Analysis of Window-based Flow Control using TCP/IP: Eect of High Bandwith-Delay Products and Random Loss", 5th IFIP Conference on High Performance Networking, Grenoble France, June 1994 [3] G. Meempat, \Interactions of Reliable Stream Data Transport Protocols with Rate Contol Algorithms", IEEE ICCCN'94, San Francisco CA USA, September 1994 [4] A. Bianco, \Performance of the TCP Protocol over ATM Networks", Francisco CA USA, September 1994

IEEE ICCCN'94

, San

[5] M.Ajmone Marsan, A.Bianco, R.Lo Cigno, M.Munafo \Shaping TCP Trac in ATM Networks", IEEE ICT'95, Bali Indonesia, April 1995 [6] M.Perlo, K.Reiss, \Improvements to TCP Performance in High-Speed ATM Networks", Communications of the ACM, v. 38, n. 2, pp. 90-100, February 1995 [7] M.Ajmone Marsan, R.Lo Cigno, M.Munafo, A.Tonietti, \Simulation of ATM Computer Networks with CLASS", 7th Int. Conference on Modelling Techniques and Tools for Computer Performance Evaluation, Vienna Austria, May 1994 [8] M.Ajmone Marsan, A.Bianco, T.V. Do, L.Jereb, R.Lo Cigno, M.Munafo \ATM Simulation with CLASS", to appear on \Performance Evaluation Journal" [9] Van Jacobson, \Berkeley TCP evolution from 4.3-tahoe to 4.3-reno", Eighteenth IETF, Vancouver BC Canada, August 1990 [10] ITU Recommendation I.371 \Trac Control and Congestion Control in B-ISDN", Geneve, Switzerland, 1992 [11] M.Ajmone Marsan, T.V.Do, L.Jereb, R.Lo Cigno, R.Pasquali, A.Tonietti, \Simulation of Trac Shaping Algorithms in ATM Networks", in: D.Kouvatsos (editor), Performance Modelling and Evaluation of ATM Networks, Chapman and Hall, London, 1995 16/10