NEW TRANSFER METHODS FOR CLIENT-SERVER TRAFFIC IN ATM NETWORKS

Transcription

1 NEW TRANSFER METHODS FOR CLIENT-SERVER TRAFFIC IN ATM NETWORKS David Lecumberri Kai-Yeung Siu* Paolo Narv6ez Massachusetts Institute of Technology Masayoshi Nabeshima Naoaki Yamanaka NlT Network Service Systems Laboratories Abstract This paper presents new transfer schemes for clientserver traffic over ATM networks, with the objective of achieving a bounded transmission time of about one second for as many connection requests as possible. We evaluate via simulations the performance of these new schemes in terms of network utilization, cell loss ratio, and transmission time. The simulation results show that these schemes provide effective means of supporting clientserver traffic with quasi-real time requirements. 1 Introduction Asynchronous Transfer Mode (ATM) is a promising technology for supporting future multimedia services. (e.g., voice, video, and data). Multiple service classes for ATM have been already described in the literature and developed specifically to carry traffic with different service requirements. Available bit rate (ABR), unspecified bit rate (UBR), variable bit rate (VBR) and ATM block transfer (ABT) service classes are some examples [l], [2], 131. The recent growth of the Internet due to the popularity of the World Wide Web has fueled a lot of research studies on how ATM can provide support for upper layer applications. In fact, most Internet traffic is web-related [4]. Traffic generated from web-related applications (simply referred to as cliendserver traffic in this paper) has some important characteristics. However, there has been little research on data transmission methods taking into account the general characteristics of cliendserver traffic. The motivation of our work is to develop better transfer methods to support such cliendserver traffic in ATM networks. In a normal web transaction, a user enters an address on the browser, i.e. it requests some data from a server. The server then transmits the requested document to the client. As opposed to conventional studies that considered each of these two flows (client to server and server to client) independent of each other, we consider them as coupled and not to be treated separately. It is also worth noticing that typically, the client sends the server a very small * Please direct all correspondence to K-Y. Siu, Rm C 77 Massachusetts Ave., MU, Cambridge, MA 02139, USA. siu@sunny.mit.edu amount of information (usually HTTP requests are around 50 bytes long), whereas the data transmitted from the server to the client is much larger (up to several megabytes). This asymmetry in the amount of information sent on each direction would be a factor in how congestion may affect network performance. Since the data sent from the client to the server is much smaller than what is sent from the server to the client, the latter traffic is what may cause congestion on the switches. Therefore, we consider that clienthewer traffic is coupled and asymmetric. We will evaluate here several new schemes that will take into account the characteristics of client-server traffic. We will first describe the general behavior of client, server and switch, and then, discuss the differences between the proposed methods. 2 New methods of transferring data We consider that traffic generated from future multimedia applications can be classified into three forms: Non-Real time communication (NRT), is store-andforward traffic like current Internet traffic. Real time communication (RT), is stream traffic like Internet telephony. Quasi-Real time communication (QRT), is a new concept and it refers to transfers of large amounts of data such as 10 Mbytes within an amount of time that is in the order of one second. Our proposed schemes address QRT communication, and their purpose is to keep the transmission time of each connection within the order of one second. Moreover, our schemes will keep high utilization of the network and a low cell loss probability. We will first describe the operation of the client. When a client sends a server data, an additional OAM (operation and maintenance) cell is sent ahead of the data. The OAM cell has a traffic field that indicates whether the data following is sent from client to server (CLIENT) or from server to client (SERVER). It also has a bandwidth field, which will be set to the maximum rate at which the client can receive data. This bandwidth field, as we will see below, will be updated along the path through the network from the client to the server. We assume the client could be a single computer but Global Telecommunications Conference - Globecom /99/$ IEEE 1345 I.H&.,

2 also a cluster of computers. These clients generate HTTP requests according to a given statistical distribution. The traffic pattern for HTTP requests can be decomposed into human generated requests and subsequent machine generated requests needed to recover included documents in a given web document, such as inlined images, etc. For the particular Quasi-Real Time (QRT) communication that we consider, we will model the generation of HTTP requests considering only the human generated requests. We employ a Poisson process in which HTTP requests are generated according to an exponential distribution, parameterized with the mean interarrival time. We claim this model is accurate for our simulations because of the human nature of HTTP requests and also because of the aggregate nature traffic when we consider the client to be a cluster of computers. Next, let us describe the behavior of the switch when receiving data from the client to the server. When the OAM cell arrives at an ATM switch, the switch recognizes that the data following is sent from client to server because the traffic field of the OAM cell is set to CLIENT. The switch monitors the value of the residual bandwidth on the reverse link where the coupled flow traverses, and it then compares the monitored value with the value in the bandwidth field of the OAM cell. It will then set the bandwidth field to the minimum value of the two, e.g. if the residual bandwidth monitored is higher than the value in the OAM cell, it will not modify that value. The residual bandwidth is monitored by maintaining a table of connections that are active at any given time on each switch. The three proposed schemes differ in the operation of the switch when receiving an OAM cell: 0 Scheme 1: Under Scheme 1, the switch will not take any further action, other than monitoring the residual bandwidth available in the reverse link. 0 Scheme2: Under Scheme 2, the switch, after monitoring the residual bandwidth available in the reverse link, will reserve it, therefore decreasing the residual bandwidth available for other requests. When the data from the server to the client arrives at the switch, it will extract from the OAM cell the rate at which the server is actually transmitting. The switch will then compare this value with the bandwidth previously reserved for that session, and it will release the extra bandwidth reserved, if any. This more conservative approach will prevent cell loss, but may keep the link underutilized when a request reserves more bandwidth than it will actually use. aggravated by the fact that most connections are likely to last for about one second, during which the queue is going to be filled and will become full very quickly. As soon as a connection releases the bandwidth, and the switch advertises this value, it is highly probable that under high load a new connection is going to use it, and again the incoming traffic is going to approach or exceed the outgoing capacity. Therefore, it will be very difficult for the queue length to be reduced, and in the event of having another collision, cell loss is likely to occur soon after the new connection gets established. The key idea of this scheme consists in releasing the bandwidth in a progressive manner, based on the available queue capacity. If the queue is almost full, then we should try to drain it before actually accepting more traffic that could fill it up again. Scheme 3 is based upon Scheme 1 in the sense that we do not reserve the bandwidth. More specifically, the switch, upon arrival of an OAM from the client, will monitor the residual bandwidth of the reverse link, R. Then it will compute the value current queue length P= maximumqueue length based on which it will adjust the value of the residual bandwidth, B, that is advertised to the server, according to the following algorithm: if (PILB) B=R else if (P2HB) B=O else B=R.- HB- P HB - LB endi f endi f where LB is the lower bound below which the switch gives all the residual bandwidth available, and HB is the upper bound above which, even though there might be some residual bandwidth, the switch will not advertise any, in order to let the queue drain. Between these two bounds, the advertised residual bandwidth will be proportional to the remaining queue capacity. Finally, let us describe the behavior of the server. Since the server may know the size of the data to transmit', it 0 Scheme 3: We realize that in Scheme 1, once there is ' This is not always the case, particularly on web transactions. a collision and the link load is over 100% (i.e., the There are an increasing number of dynamic contents on the web, incoming traffic is more than the bottleneck link Can where the documents are generated on-the-fly. For these handle), the queue is likely to overflow. This is applications, the server does not know in advance the size of the document to be transmitted. Global Telecommunications Conference - Globecorn'99

3 . High Speed Networks calculates the value D (cellds), which is the size of the requested data divided by the targeted transfer time, such as one second. The server also obtains the value of the residual bandwidth R (cellsls) available in the reverse path from the bandwidth field of the OAM cell, The server can determine the transmission rate for sending data to the client using the minimum value of R and D (or the remaining bandwidth at which the server can transmit). A multiplicative parameter a (set to 0.9) is also applied to the actual bandwidth to be used. In this way, the server will only see a times the bandwidth that the network advertises. It will also determine that the connection cannot be established if the available rate R falls below a lower bound, which we specify as a fraction of the desired transmission rate D. Upon deciding the rate at which it is going to send data to the client, the server will then send an OAM cell ahead of the data. This cell will have its traffic field set to SERVER, and in the bandwidth field, the rate at which the server is actually sending. It will also send an additional OAM cell following the last ATM data cell for every transmission, with the traffic field set to CLOSE. This additional OAM cell imposes a negligible overhead to the server; its purpose is to help the switches compute the active (i.e. currently consumed) and residual bandwidth, qd allow the clients to close and collect statistics about a connection. Two important parameters to set at the server are the data size distribution and the lower bound on the available bandwidth below which the server will declare a backoff and will not send any data at all. For the data size distribution, we have chosen a very heavy tailed distribution ranging from 200 Kbytes to 10 Mbytes, with a mean data size of 4.92 Mbytes, i.e Mbits. For the backoff lower bound, we declare a backoff when the transmission time is going to be more than five times the target time for a particular transmission, i.e. if the transmission is going to last more than 5 seconds. 3 Expected performance, preliminary analysis We will employ a very simple configuration, in which three clients share the same bottleneck link in their connections to three servers. This simple configuration, because of its symmetry, will provide information about the fairness of the scheme and easily separate the influence of each parameter on the performance of each scheme. The bandwidth contention (i.e. load) on the network is determined by four parameters. Three of them are fixed at the network level and the remaining (client request frequency) will be fixed at the simulation level: Round-trip times: Propagation delays are set to 1 ms for the links connecting either clients or servers to the switches and 5 ms for the link connecting the two switches, therefore having a round-trip time of 14 ms. Link speeds and buffer space: all links in the network model are identical duplex links, transmitting at 100 Mbps. This is going to create a bottleneck in the link connecting the two switches, over which we can test the performance of the three schemes. For this link speed, our choice of buffer size is 5,000 cells per outgoing link at each switch. Size of the data to be transmitted: As it was mentioned in the server description, we use a heavy tailed distribution of sizes, with' a mean value of 4.92 Mbytes of data to send per request. Frequency at which clients request data from the servers. We want to test the behavior of the three schemes and compare their performance under different parameters. We want to put a very heavy load on the network, so we can test how the three schemes differ. For the particular topology that we are using, the load on the network is going to be determined by the frequency at which clients request data from the servers. We have a bottleneck link with a capacity of 100 Mbps, three clientlserver pairs and a mean rate desired by the server of 4.92 Mbyteslsec per connection, that is Mbpslsec or a 39.36% of the link capacity. Therefore, we need to have at least one request per client per second to maintain a moderate load. Each of the parameters will a have a different impact on the performance of the three schemes. The main purpose of the three schemes is to keep the transmission time close to a target time of one second. Therefore, with all transmissions lasting a time period in the order of one second, the ratio between the link capacity and the mean size of the data will determine the number of simultaneous transmissions a particular link can handle. If the data size is large compared with the link capacity, we are allowing just a few transmissions on the link, forcing other transmission requests to backoff. This may cause unfairness over a short period of time (in the order of a few seconds) because a connection eventually could obtain and maintain a large amount of bandwidth. Under these circumstances, having a higher request frequency at the client is going to translate into a larger number of backoffs, but the transmission time of connections that get established is not going to be dramatically affected, specially in Scheme 2. Therefore, the ratio between the client request frequency and the round-trip time is going to be the most important factor determining the performance. As intuition may indicate, the difference between the three schemes will depend on how frequently the requests are sent from the clients. If the mean interarrival time for two consecutive requests is much larger than a round-trip - Global Telecommunications Conference - Globecom' _ ~

4 time, then the performance perceived by the users will be quite similar for the three schemes. If, however, the roundtrip time and interarrival times are comparable (or the interanival times are smaller than the round-trip time), switches using Schemes 1 and 3 will experience more cell loss, as it may happen that many servers attempt to use the same residual bandwidth and therefore overwhelm the switch. On the other hand, switches using Scheme 2 will be much more conservative, as they will reserve capacity on a link just for the first attempted connection. Although this scheme will not cause any cell loss, it will result in a larger number of sessions being rejected and underutilization of the link bandwidth. 4 Simulation results and discussion The main purpose of the simulations is to verify the correctness of the analysis and expected performance. In order to do that we need to stress the network in such a way that the differences of behavior of the three schemes can be shown. It is also necessary in order to understand how the three proposed schemes will work. We define a notion of collision window, which is the time elapsed since an OAM cell carrying a request for a connection from a client passed through a switch until it returns to the switch, followed by the actual data. In general, this window will vary from switch to switch and it will be equal to a round-trip time from the switch to the server. In Scheme2, during this time, the residual bandwidth of the link will be reserved but not used. In Scheme 1 and 3, if another request anives from a client during this time, it may lead to an overload of the link, since the two connections will think they have the same residual bandwidth available. We will define this event as a collision. In the event that there is no collision, all schemes will behave identically, since the state of the switch seen by the connection request will be the same regardless of the scheme used. 4.1 Performance under moderate load We first prepared a set of simulations in which the 3 clients were performing 4 requests per second. That means having 12 requests per second overall and an average traffic load per second of 4.92 Mbyteslsec x 8 bitshyte x 12 requests = 472 Mbps. This rate is 4 times more bandwidth than what the bottleneck link can handle. This corresponds to having a request through the switch every 83 ms on average, when the round-trip time (i.e. the collision window), from the last switch to the server is 2 ms. This implies that the possibility of having two requests coming during the collision window is unlikely. Therefore, the behavior of the three methods under these conditions should be quite similar. From the simulation results, we verify that our intuition of the similar performance of the three schemes is correct. The utilization of the network is the same for the three methods (92.2% on average). The cell loss is zero in all three cases, which is also consistent with the fact that no two connections collided over the duration of the simulation. However, even though the traffic requests exceed the link capacity, the link is still under-utilized. The link remains partially utilized for some time, even though there is also a large number of connections that get backed off (72%). This happens, again, because the number of requests per second is small. While the link is fully utilized, many connections have to be backed off; however, when a connection finishes, therefore increasing the residual bandwidth, it takes some time until a new connection request for that bandwidth is initiated by a client. 4.2 Performance under high load We also performed another set of simulations, in this case increasing the request frequency of the clients up to 100 requests per second. This means having a request at the bottleneck link every 3.33 ms. Since the collision window is 2 ms, we expect to see differences in the behavior of the three proposed methods Scheme 1 For Scheme 1, we start seeing collisions, i.e. more than one connection got established with the perception that a given amount of residual bandwidth is available to each connection. Since there is no mechanism to lower the transmission rate of the servers even when the switch is experiencing cell loss, the servers will keep sending at the same speed, once the connection is established. This will cause, as we see in Figure 1, the queue in the bottleneck link to overflow and, therefore, experience cell loss. Eventually, when the competing connections are finished, and if there were no further collisions, queues would drain Queue Size Time (5) Figure 1: Queue sizes for each scheme,1348 Global Telecommunications Conference - Globecom 99

5 60 Cell Loss Probsbillty Distrlbutlon ae -.+-.Scheme 1 U ---Scheme 3 n Cell Loss Probability (%) Figure 2: Cell loss probability distribution However, since the request frequency is very high, the queue will not be drained and will keep experiencing cell loss. However, the link is fully utilized, thus maximizing the transmission over the bottleneck link. The overall cell loss ratio (total cells lost over total cells sent) is 4.53%. We also provide a distribution of cell loss on a per connection basis, shown in Figure 2. We can see from that figure that the loss ratio is not evenly distributed and most connections either have no cell loss or experience around 8% cell loss. This is explained by the fact that cell loss is not happening continuously, but only for transmissions in which a collision occurred. Therefore we should expect this kind of bimodal distribution Scheme 2 From the simulation for Scheme 2, we see how this more conservative scheme, in which we guarantee that the residual bandwidth advertised is always available, prevents cell loss. This is not surprising since the switch guarantees that even when a collision occurs, only the first connection arriving will get the residual bandwidth on the OAM cell. Utilization of the link in Scheme 2 is slightly lower than in Scheme 1, although it is very high (98.3%) due to the very high frequency of client requests. In Figure 1, we show how the queue remains almost emptg, supporting the fact that there is no cell loss at all. The backoff probability is similar to Scheme 1, and since the number of requests accepted is so small with respect to the number of requests attempted, we cannot extract any conclusion from the comparison of backoff ratios for Scheme 1 and Scheme 2. Analysis and intthtion indicate that backoff in Scheme 2 should be higher than Scheme 1, but this claim cannot be verified with our simulations. Concerning the distribution of total transmission time, similarly to Scheme 1, most of the connections get * The reason why there is a nonempty queue is that O M cells use up some bandwidth, which is not accounted for. transmitted within the target time. However, given that in Scheme 2 there is no cell loss, and the link remains highly utilized, we conclude that under extremely high load, Scheme 2 outperforms Scheme Scheme 3 We performed a new set of simulations under the same high load conditions and we observed the expected improvement over Scheme 1. We set LB to 0.2 and HB to 0.5, i.e. when the queue occupancy is below 20%, we will release all the residual bandwidth available and when it is above 50% we will advertise zero residual bandwidth, even though we could eventually have some. The link load is quite similar to what was obtained for Scheme 1. We still see overloading of the bottleneck link. However, with the progressive releasing of the bandwidth, we are allowing the queues to drain before over-utilization occurs again. The difference with Scheme 1 can be clearly seen in Figure 1. Cell loss occurs only when there is queue overflow. Comparing this with the queue size for Scheme 1, we can see how cell loss occurs much less often in Scheme 3. The absolute cell loss ratio is 2.11%. Moreover, since the queue is never empty, we are guaranteeing that the link is fully utilized. Therefore, there is an improvement in performance, since cell loss is reduced and link utilization keeps being 100%. We also point out that, in addition to the fact that the overall cell loss probability is reduced, having the queues drained before the possibility of having losses again decreases the cell loss ratio on a per connection basis. As we can see from Figure 2, the cell loss distribution does not have the same bimodal characteristic as in Scheme 1, since most of the connections are experiencing a cell loss ratio close to zero. Finally, the transmission times are similar to those in Scheme 1 and 2. However, we expect Scheme 3 to be slightly better than Scheme 1, because having the queues less populated will tend to decrease the queuing delay. Hence, the transmission time would be slightly less. References [I] The ATM Forum, Traffic Management Specification Version 4.0, April [2] ITU-T 1.371, Traffic control and congestion control in B-ISDN, Geneva, Switzerland, Aug [3] B. Vandalore, S. Kalyanaraman, R. Jain, R. Goyanl, and S. Fahamy, Performance of Bursty World Wide Web (WWW) Sources over ABR, WebNet 97, Toronto, Nov [4] K. Thompson, G. J. Miller, and R. Wilder, Wide- Area Internet Traffic Patterns and Characteristics, IEEE Network, Nov./Dec Global Telecommunications Conference - Globecom