Fair and reliable hop-by-hop flow control

Computer Communications 22 (1999) 1227–1233

Fair and reliable hop-by-hop flow control 夽 W.K. Lai*, D.-R. Shiu, M.-C. Liou, J.-Y. Tsai Institute of Computer and Information Engineering, National Sun Yat-Sen University, Kaohsiung, Taiwan Received 19 October 1998; received in revised form 13 May 1999; accepted 14 May 1999

Abstract Asynchronous transfer mode networks can support different services with different quality of service requirements. Among all service types, available bit rate (ABR) is used primarily for transferring data files. Flow control is essential in ABR service. In this paper, we propose a new hop-by-hop credit-based flow control scheme with shared buffers. In this scheme, we introduce the concept of request cells to let upstream stations request credits from downstream stations such that downstream stations know the transmission requirements of upstream stations in the early stages of transmission. This allows the downstream stations to arrange their buffer spaces for different virtual connections (VCs) according to real needs, priorities, and fair access of different VCs. Simulation results show that the scheme improves the total throughput compared to the traditional credit-based flow control scheme, flow controlled virtual connections, without shared buffers under the same conditions. In one simulation, the total throughputs are increased by as many as 16.4%. 䉷 1999 Elsevier Science B.V. All rights reserved. Keywords: Credit-based flow control; Asynchronous transfer mode; Request-based flow control

1. Introduction Due to the rapid development of network technology, different types of sources such as voices, images, data and video can now be transmitted in asynchronous transfer mode (ATM) networks. The various classes that the ATM forum defined for UNI 4.0 are listed as follows: Constant bit rate (CBR). This CBR service class is primarily used for emulating circuit switching. End systems use the CBR class to carry traffic that needs a constant bit rate and has fixed timing relationship between cells. Examples of application, which can utilize this class are telephone services, videoconferences and televisions. Variable bit rate-real time (VBR-RT). This service class is used for traffic that has timing relationship between cells. An example suitable for this class is interactive video compression. Variable bit rate-non-real time (VBR-NRT). This service class is used for connections with variable bit rates and there is no timing relationship between cells. An example of this class is multimedia email. Available bit rate (ABR). This service class is designed 夽 This work is supported in part by the National Council of Taiwan, under contract no. NSC85-2221-E-110-005. * Corresponding author. Tel.: ⫹ 886-7-525-2000/4312; fax: ⫹ 886-7525-4301. E-mail address: [email protected] (W.K. Lai)

for normal data traffic such as files and emails. ABR class does not have any timing relationship between cells and does not provide any guaranteed bandwidths to users. Although the standard does not guarantee cell transfer delays and cell loss ratios, flow control can help reducing them. In ABR, the source adjusts its rates depending upon the congestion states of the network. ABR class aims to provide the “best-effort” service. ABR is ideal for carrying local area network (LAN) traffic over ATM networks. Unspecified bit rate (UBR). The UBR class uses any bandwidth not used by the above four classes. This service class is designed for those applications that are not sensitive to cell losses or delays. There are no flow control mechanisms or admission control mechanisms implemented for this class. The UBR class does not offer any service guarantees. During congestion, the sources do not reduce their cell rates. Examples of applications that can use this service class are emails and file transfers. From the above discussion, we know that the ABR class is ideal for flow control. Flow control can be classified into rate-based flow control and credit-based flow control [1]. In the rate-based flow control, cells in general do not have any loss guarantees. This is because in rate-based control, endto-end flow control is implemented. The control cycle is long and the response of the sender to the feedback cells may not be quick enough. However, rate-based flow control is relatively easy to implement. Only two end switches are necessary to implement complex functions. Examples of

0140-3664/99/$ - see front matter 䉷 1999 Elsevier Science B.V. All rights reserved. PII: S0140-366 4(99)00122-X

1228

W.K. Lai et al. / Computer Communications 22 (1999) 1227–1233

rate-based flow control are forward explicit congestion notification (FECN) [2], backward explicit congestion notification (BECN) [3], proportional rate control algorithm [4], adaptive proportional rate control (APRC) [5], enhanced proportional rate control algorithm (EPRCA) [6], etc. On the contrary, credit-based flow control is usually hopby-hop flow control. Thus, it has a short control cycle and the station can respond to feedback cells quickly. Another advantage of credit-based flow control is that as every intermediate switch is involved in flow control, queues in each intermediate station can be used to buffer congestion traffics. Hence, credit-based flow control can guarantee zero cell loss. However, each switch is involved in flow control. Examples of credit-based flow control are flow controlled virtual connections (FCVC) [7], sender-oriented buffer allocation [8,9], receiver-oriented buffer allocation [10], etc. Fig. 1 is a basic credit-based flow control model. FCVC scheme is the first credit-based flow control method proposed. In each station, the FCVC scheme reserves a queue for each VC (per-VC queuing). Within each VC, the downstream station sends credits to the upstream station each time when the downstream station has forwarded N

Upstream station must receive credits from downstream station before transmitting data.

Credit Data

Credit Credit

Data

Data Data

Data Credit Credit

Per VC Buffer

Fig. 1. A basic flow control model.

Sender

Intermediate node

R

Cell Transfers

Managing Requests & Adaptive Allocation

Updating Credits

Updating Credits

R

C C

Forwarding Cells

Intermediate node Managing Requests & Adaptive Allocation

R

R Receiver

C

Managing Requests & Adaptive Allocation

C

Updating Credits

Forwarding Cells

R

Request

Receiver

Receiving cells

C

Credit

Cell

Fig. 2. Block diagram of the request-based flow control.

W.K. Lai et al. / Computer Communications 22 (1999) 1227–1233

1229

150 Mbps

150 Mbps

S1

D1

50 Mbps

75 Mbps

SW1

SW2

SW3

L1

L2

S2

D2 150 Mbps

150 Mbps

Fig. 3. Network topology to demonstrate the request-based flow control.

cells to its downstream station, where N is a natural number and can be adjusted. The downstream station has a forward counter, fc, to record the credits. The upstream station has a transmission counter, tc, to record the total number of cells sent by the upstream station, between the time when it receives credits and the time when it last received credits. The credit balance, cb, for the upstream station can now be obtained as follows: cb ˆ number of buffers ⫹ fc ⫺ tc. FCVC will be compared with our method discussed in Section 3. To reduce the required buffers, both the send-oriented buffer allocation and the receiver-oriented buffer allocation adopt the concept of shared buffers. Ozvern, Simcoe and Varghese proposed a sender-oriented scheme that is simpler and requires fewer resources in implementation [9] than the receiver-oriented scheme proposed in Ref. [10]. However, the receiver-oriented buffer allocation is more efficient in terms of the total number of buffers required [10]. Hence, the paper will focus on the receiver-oriented buffer allocation and propose a simple receiver-oriented scheme (RFC). In the RFC, downstream stations send credits to upstream stations as previous schemes. The difference between the RFC scheme and the previous schemes lies in the aspect

Cell number

Buffer Occupancy of VC2 in SW1

Time (second)

(a)

that upstream stations also send requests to downstream stations. When there are many VCs passing through the downstream stations, this allows the downstream stations to arrange their buffer spaces for different VCs according to real needs, priorities, and fair access of different VCs. This paper will focus on the RFC scheme itself. The paper is organized as follows. The introduction is given in Section 1. The requested-based flow control method (RFC) is explained in Section 2. Simulation results of the RFC and the comparisons between the RFC and the FCVC schemes are presented in Section 3. Conclusions are given in Section 4.

2. Request-based flow control (RFC) The block diagram of the RFC scheme is shown in Fig. 2. The block diagram consists of one sender, one receiver, and some intermediate stations. In each station, each virtual connection i is given a queue length, MRBi. Each virtual connection i also has an available credit counter, CCi. CCi is increased by one when the station receives a credit from downstream station and is decreased by one when the station forwards a cell to downstream station. Moreover,

Cell number

Buffer Occupancy of VC2 in SW1 (RFC)

Time (second)

(b)

Fig. 4. The buffer occupancy of VC2 in SW1 for the FCVC scheme (a) and the RFC scheme (b).

1230

W.K. Lai et al. / Computer Communications 22 (1999) 1227–1233

Buffer Occupancy of VC2 in SW2

Cell number

Cell number

Buffer Occupancy of VC2 in SW2 (RFC)

Time (second)

Time (second)

(a)

(b)

Fig. 5. The buffer occupancy of VC2 in SW2 for the FCVC scheme (a) and the RFC scheme (b).

common buffer spaces with size, SC, are shared by all virtual connections. In the RFC, the function of a sender consists of two parts: cell transfers and updating requests. The function of an intermediate station consists of three parts: managing requests and adaptive allocation, updating requests, and forwarding cells. In the same way, the function of a receiver consists of two parts: managing requests and adaptive allocation, and receiving cells. In a sender, the function of cell transfers is responsible for sending cells. For incoming cells of length L in connection i, RFC checks its available credits (CCi) for this particular connection. A positive CCi means there are still available credits. If there are no available credits in connection i, the sender sends a request cell, Request(i,L), to the downstream station, which means there are L requests for the connection i. If the arrival cells are longer than the available credits, the sender sends a request cell, Request(i,L ⫺ CCi), to the downstream station and forwards as many as CCi of cells.

If the arrival cells are less than the available credits, the sender simply sends cells of length L to the next station. The function of updating credits simply increases its credits for virtual connection i by C when it receives C credits from the previous station. For an intermediate station, an additional counter, forward counter FCi, is needed for each virtual connection i. The forward counter is used to record the number of cells sent to the downstream station, and to control the number of credits sent to the previous station. Its value is increased by one each time the station forwards a cell to the downstream station and is decreased by one each time the station sends a credit to the upstream station. In managing requests and adaptive allocation, let us assume that the request cell for connection i is Request(i,Ri). If FCi is greater than Ri, there are enough spaces in the receiver buffer, and the intermediate station sends Ri credits, Credit(i,Ri), to the previous station. Otherwise, the intermediate station sends FCi

20620

25000 18873

cell number

20000 15000 10000

5068

FCV C RFC

5061

5000 0

1

2 V C num ber

Fig. 6. The total number of cells received by the receiver station D1 of VC1 and D2 of VC2.

W.K. Lai et al. / Computer Communications 22 (1999) 1227–1233 Cell number

Buffer Occupancy of VC2 in SW1

Cell number

1231

Buffer Occupancy of VC2 in SW1 (RFC)

Time (second)

Time (second)

(a)

(b)

Fig. 7. The buffer occupancy of VC2 in SW1 for the FCVC scheme (a) and the RFC scheme (b) with VC1 blocked.

credits, Credit(i,FCi), to the previous station and saves the remaining requests. The remaining requests are served later by a round-robin routine to share the common buffer spaces with other connections. The intermediate station then checks if its CCi is less than the requests from the upstream station plus the number of cells in the queue i. If this is true, it means the current credits are not enough to forward all the cells in the queue i and the upcoming cells from the upstream station. Therefore, the intermediate station sends a request cell, request(i,Ri ⫹ QueueLength ⫺ CCi), to the downstream station. Updating credits in an intermediate station is simply updating available credits similar to updating credits in the sender. As regards the function of the forwarding cells, each time a station forwards a cell, the value of CCi is decreased by one. If the number of cells Cell number

Buffer Occupancy of VC2 in SW2

Time (second)

(a)

in the queue is greater than or equal to MRBi, the released buffer space is returned to the common buffer spaces. If the current cell number is less than MRBi, FCi is increased by one. For the receiver, the function of managing requests and adaptive allocation is similar to the intermediate station only, without sending requests to the next station. The function of receiving cells is to retrieve cells from the receiver buffers. Each time a cell is consumed in the receiver buffer, CCi is decreased by one.

3. Simulation results In this simulation, we compare the results of the FCVC Cell number

Buffer Occupancy of VC2 in SW2 (RFC)

Time (second)

(b)

Fig. 8. The buffer occupancy of VC2 in SW2 for the FCVC scheme (a) and the RFC scheme (b) with VC1 blocked.

1232

W.K. Lai et al. / Computer Communications 22 (1999) 1227–1233

32166 33000 32000

cell number

31000 FCVC RFC

30000 27633 29000 28000 27000 26000 25000 Fig. 9. The total number of cells received by the receiver station D2 of VC2.

scheme and our scheme. The network topology for the simulation is shown in Fig. 3. There are two senders, S1 and S2, two receivers, D1 and D2, and three switches, SW1, SW2, and SW3. One connection, VC1, is from S1 to D1 and the other connection, VC2, is from S2 to D2. The buffer size is 200 cells for each sender, receiver, and switch. In the FCVC scheme, there are no shared buffers and buffers in each switch are equally divided with 100 cells per VC. For our scheme, buffers are divided into shared and dedicated buffers. 100 cells are shared and 50 cells are reserved for each VC. The burst length of the sender is 1.26 ms and the interval between the bursts is 3.6 ms. The frequency of feedback cells is …1=81† × 106 s ⫺1 for both the schemes. The frequency of request cells for our scheme is …1=81† × 106 s ⫺1 and the round-robin cycle for our scheme is 1:62 × 10⫺4 s. The simulation time is 0.3 s. In the first simulation, the mean burst generation rate is 8 cells/ms for VC1 and 1920 cells/ms for VC2. The output bandwidth for SW3 to D1 and SW3 to D2 is 150 Mbps each. The input bandwidth to SW3 is only 50 Mbps. Hence, we will need very few buffers in SW3. Thus, we only show the buffer occupancy in SW1 and SW2. As the mean burst generation rate is slow for VC1, the buffer occupancy of VC1 is less than 20 cells in each switch for both schemes. Hence, we only show the buffer occupancy of VC2 in SW1 and SW2 here. In Fig. 4, the buffer occupancy of VC2 in SW1 is shown. The FCVC scheme is on the left and the RFC scheme is on the right. Without shared buffers, the cells in the buffers cannot exceed 100 cells for VC2. On the contrary, the cells in the buffers can be as many as 150 cells for the VC2 in the RFC scheme. Fig. 5 is the buffer occupancy of VC2 in SW2 for the FCVC scheme (left) and the RFC scheme (right). Fig. 6 shows the total cells received in D1 and D2. For D1 of VC1, both schemes are almost same with 5068 cells for the FCVC scheme and 5061 cells for the RFC scheme. For D2 of VC2, the cells received in the RFC scheme are about 9.3% more than the FCVC scheme, 20620 cells for the RFC scheme versus 18873 cells for the FCVC scheme. In total, the total cells received in D1 and D2 for the RFC scheme is 25681 cells for the RFC

scheme and 23941 cells for the FCVC scheme. Overall, the cells received in the RFC scheme are about 7.26% more than the FCVC scheme. In the second simulation, the network topology is unchanged. We assume the burst generation rate of VC2 to be 1920 cells/ms and the burst generation rate of VC1 to be zero. It happens when VC1 is blocked or idle. The other parameters are the same as the first simulation. Fig. 7 shows the buffer occupancy of VC2 in SW1 for both schemes, and Fig. 8 shows the buffer occupancy of VC2 in SW2 for both schemes. The cells in the buffers can be as many as 150 cells for VC2 in the RFC scheme and cannot exceed 100 cells for the VC2 in the FCVC scheme. Fig. 9 shows the total cells received by the receiver station D2. It is 32166 cells for the RFC scheme and 26733 cells for the FCVC scheme. Thus, the cells received in the RFC scheme is about 16.4% more. 4. Conclusions In this paper, a request-based flow control scheme is proposed. This scheme has the advantage of sending requests from upstream stations to downstream stations in early stages of cell transmission. When there are many VCs passing through the downstream stations, this scheme allows the downstream stations to arrange their buffer spaces according to real needs, priorities, and fair access of different VCs. The scheme is simple, efficient, and fair. Simulation results show that the total throughputs are increased compared to the FCVC scheme under the same conditions. References [1] Q. Li, Z. Wang, A comparison study of congestion control for ABR service in ATM networks, University College London, 1995. [2] B.A. MaKrucki, Forward explicit congestion notification in ATM networks, in: Proc. TriComm’92, 1992. [3] P. Newman, Backward explicit congestion notification for ATM local area networks, in: Proc. IEEE GLOBECOM’93, 1993.

W.K. Lai et al. / Computer Communications 22 (1999) 1227–1233 [4] L. Roberts, Closed-loop rate-based traffic management, ATM Forum Contribution 94-0438, 1994. [5] K.Y. Siu, H.Y. Tzeng, Adaptive proportional rate control (APRC) with intelligent congestion indication, ATM Forum Contribution 94-0888, 1994. [6] Y. Lai, Y. Lin, Interoperability of EFCI and ER switches for ABR services in ATM networks, IEEE Network 12 (1998) 34–43. [7] H.T. Kung, A. Chapman, The FCVC (Flow-Controlled Virtual Channels) proposal for ATM networks, version 2.1, in: Proc. 1993 International Conf. On Network Protocols, 1993.

1233

[8] H.T. Kung, T. Blackwell, A. Chapman, Credit-based flow control for ATM networks: credit update protocol, adaptive credit allocation, and statistical multiplexing, in: Proc. ACM SIGCOM ’94 Symposium on Communication Architectures, Protocols and Applications, 1994. [9] C. Ozveren, R. Simcoe, G. Varghese, Reliable and efficient hop-byhop flow control, in: Proc. ACM SIGCOM ’94 SYMPOSIUM on Communication Architectures, Protocols and Applications, 1994. [10] H.T. Kung, C. Chang, Receiver-oriented adaptive buffer allocation in credit-based flow control for ATM networks, in: IEEE INFOCOM’95, 1995.