THROUGHPUT IN THE DQDB NETWORK y. Shun Yan Cheung. Emory University, Atlanta, GA 30322, U.S.A. made the request.

Transcription

1 CONTROLLED REQUEST DQDB: ACHIEVING FAIRNESS AND MAXIMUM THROUGHPUT IN THE DQDB NETWORK y Shun Yan Cheung Department of Mathematics and Computer Science Emory University, Atlanta, GA 30322, U.S.A. ABSTRACT We propose an extension of the Distributed Queue Dual Bus (DQDB) protocol called Request Controlled DQDB that can achieves 00% channel utilization and has similar sharing properties as the bandwidth balancing method. Transmission of requests in the Request Controlled DQDB method is controlled by a mechanism that is similar to the one used in DQDB to transmit segments. The bandwidth balancing method is used to refrain an overloaded node from transmitting requests continuously. By balancing the number of requests transmitted we achieve fair sharing of data slots without wastage. A simulation study shows that the Request Controlled DQDB protocol solves the unfairness problem in DQDB while maintaining 00% ef- ciency. The study also shows that DQDB networks using the Controlled Request method can be highly responsive to changes in the oered load and have better message delay than networks that use Bandwidth Balancing. Introduction The Distributed Queue Dual Bus (DQDB) [] is now the Medium Access Control (MAC) protocol for the IEEE Metropolitan Area Network (MAN) [2]. It is designed to operate in high-speed networks spanning long distances. The DQDB network consists of two slotted busses implementing unidirectional communications in opposite directions. Nodes communicate with each other by transmitting xed size segments in the proper direction. When a segment is sent in one direction, a corresponding request is sent in the opposite direction. The y This work was supported in part by the University Research Committee of Emory University. request is used to notify nodes with prior access of the slots that a node is waiting for an empty slot. A node grants the request by refraining from transmitting in an empty slot and allowing it to be used by the node that made the request. There is a number of performance studies [3, 4, 5, 6, 7, 8] of the various releases of the standardization process. The throughput of dierent nodes under overload trac condition was studied in [3] and it was found that the throughput of a node depends on its position and the time it rst starts transmitting. The node that starts transmitting rst can monopolies the channel. The unfairness is caused by the fact that an overloaded node will continuously transmit segments in one direction and requests in the other. Nodes that are located downstream from the overloaded node will nd all slots lled with segments and nodes upstream will receive a continuous stream of requests. The Bandwidth Balancing technique was proposed in [6] to solve the unfairness problem and it was incorporated into the October 989 version (Draft 0) of the standard. The solution is to refrain an overloaded node from transmitting in all slots allowing downstream nodes to acquire more slots. By refraining from transmission, an overloaded node also sends fewer requests upstream. The upstream nodes will let fewer empty slots pass by and use more slots themselves. However, the throughput in DQDB using Bandwidth Balancing is less than 00% because a fraction of the slots will remain unused. In this paper, we present a new technique, called Controlled Request, to combat the unfairness problem in DQDB that achieves 00% throughput. In Controlled

2 Request DQDB, the transmission of requests is controlled by a mechanism similar to the one used in DQDB to transmit segments. Fairness is achieved by using the Bandwidth Balancing technique to refrain an overloaded node from continuously transmitting requests. Simulation studies show that the Controlled Request DQDB scheme achieves better performance than the DQDB protocol with Bandwidth Balancing. The paper is organized as follows. Section 2 briey reviews the Bandwidth Balanced DQDB scheme and Section 3 presents the Controlled Request DQDB protocol. In Section 4, we study the performance of the Controlled Request DQDB protocol and compare it with the Bandwidth Balanced DQDB method. Section 5 concludes the paper. 2 Bandwidth Balanced DQDB Figure shows a DQDB network of three nodes. The transmission protocol on the busses are identical in both directions and we will describe the operation in only one direction. The busses are used to transmit segments in one direction and requests in the other. We will call the bus that carries segments the data bus and the other bus, carrying requests in the opposite direction, is the request bus. Bus A in Figure is the data bus and it is used to send segments from node to nodes 2 and 3, and from node 2 to node 3. Bus B is the request bus and will carry requests from node 3 to nodes and 2, and from node 2 to node. Upstream and downstream nodes are nodes with prior and later access to slots on the data bus, respectively. For example, nodes and 3 are located upstream and downstream, respectively, from node 2. In DQDB, a node that transmits a segment on the data bus also transmits a request on the request bus to notify upstream nodes that a node is waiting for an empty slot. The header of a DQDB slot contains a busy and a request bit. The busy bit is used to indicate if the slot is empty. It is initially zero and is set to one when a node inserts a segment into the slot. The request bit is used by the nodes to make requests. For example, in Figure, when node 2 transmits a segment to node 3, Bus B (request bus) Busy bits 2 Request bits Figure : A DQDB network 3 Bus A (data bus) it also transmits a request to node. Node will grant the request by refraining from transmitting in an empty slot and allowing it to be used by node 2. Each node uses a pair of count-down (CD) and request (RQ) counters to coordinate the transmission of segments. A node is in the count-down state if it has segments to be transmitted and otherwise it is in the idle state. Each time a node receives a request, the RQ counter is incremented by one. When the node receive an empty slot in the idle state, the RQ counter is decremented by one. The RQ counter thus records the number of unsatised requests made by nodes downstream. When a node schedules a segment for transmission, it copies the value of the RQ counter to the CD counter, sets the RQ counter to zero and schedules a request for transmission on the request bus. The CD counter initially contains the number of requests that are made prior to scheduling the segment. When the node receives an empty slot in the count-down state, the CD counter is decremented by one until it reaches zero. The node will transmit the segment in the next empty slot when the CD counter is zero. The CD and RQ counters thus implements a distributed queueing mechanism. The transmission of requests is not controlled by counters. A node will send a request whenever the number of requests is greater than zero and the request bit in a slot on the request bus is not equal to one. The basic DQDB protocol was extended with the Bandwidth Balancing method to improve fairness. The Bandwidth Balanced DQDB (BB-DQDB) protocol uses a trigger mechanism to prevent an overloaded node from 2

3 continuously transmitting segments. Each time a node transmits a segment a trigger counter is incremented by one. When this counter reaches the value, it is reset to zero and the RQ counter is articially increased by one to force the node to leave one slot empty. The value of must be chosen carefully as it has profound impact on system performance. The fraction of spare capacity left over when there are exactly M overloaded? nodes in the system is equal to, where = +(M?) + [6]. The network utilization in BB-DQDB increases with the number of overloaded nodes and tends to one in the limit. The value of also aects the rate in which the slots are re-distributed among the nodes when the offered load to the system changes. A lower value of will result in a BB-DQDB system that responds more quickly to changes in the oered load, but the system will also leave a larger fraction of slots unused. 3 Controlled Request DQDB The Controlled Request DQDB (CR-DQDB) protocol uses two pairs of count-down and request counters, (CD, RQ) and (CD RQ, RQ RQ), to coordinate the transmissions of segments and requests, respectively. A node that transmits a request in one direction must also transmit a \request-to-transmit-a-request" in the opposite direction. For example, in Figure 2, if node 2 transmits a segment to node 3, it will transmit a request to node and a request-to-transmit-a-request to node 3. The slot header in CR-DQDB contains, in addition to the busy and request bits, a request-request (RQRQ) bit. The RQRQ bit is used to notify other nodes that a node wants to make a request. Bus B (request bus) Busy bits 2 Request bits RQRQ bits 3 Bus A (data bus) Figure 2: A Control Request DQDB network Transmission of segments are coordinated by using the CD and RQ counters and the operation is similar to that in DQDB. A new segment is scheduled by copying the value of the CD counter to the RQ counter. Each time the node receives an empty slot on the data bus, the CD counter is decremented by one. When the CD counter is zero, the node will transmit the segment in the next empty slot on the data bus. The Bandwidth Balancing technique is not applied to the segment transmission. The main dierence between the CR-DQDB and the DQDB protocol is the manner in which the requests are queued and scheduled for transmission. In DQDB, a request is queued for transmission on the request bus only when the corresponding segment is scheduled on the data bus and the requests for a multi-segment message are queued one at a time. In CR-DQDB, the requests for all segments are queued when the rst segment of the message is being transmitted. The number of requests queued is equal to the number of segments in the message. Hence, it is possible for a node using CR-DQDB to nish sending the requests of a multi-segment message before the last segment of the message is scheduled for transmission. This is not possible in DQDB. The schemes presented in [9] and [0] also allow a node to transmit multiple requests but they do not use a counter mechanism to regulate request transmissions. The transmission of requests in DQDB is uncontrolled, i.e., a node will transmit a request if there are requests queued and the request bit in the slot on the request bus is not set. In CR-DQDB, however, transmission of requests is controlled by a counter mechanism similar to the one used in controlling segment transmissions. A new request is scheduled for transmission by copying the value of the RQ RQ counter to the CD RQ counter, setting the RQ RQ counter to zero and scheduling a request-to-transmit-a-request on the data bus. The node decrements the CD RQ counter by one each time it receives a slot on the request bus with a request bit value zero. When the CD RQ counter becomes zero, the node transmits a request in the next slot with a request 3

4 bit value zero. The next request is then scheduled and the process is repeated until all requests or all segments for the message are transmitted. It is possible that the segments of message are transmitted before the requests for the same message. In that case, there is no need to send the remaining requests and they are canceled. The cancellation of unnecessary requests is a feature also found in the rst IEEE standard proposal that included the stand-by state. Finally, the transmission of the requests-to-transmit-a-request is uncontrolled. The CR-DQDB scheme uses the bandwidth balancing technique to refrain overloaded nodes from transmitting requests continuously. Since the transmission protocol for request bits in CR-DQDB is the BB-DQDB protocol, we can apply the results in [6] to obtain results on request transmissions for nodes using CR-DQDB. We have that the request control rate R req is equal to [6]: R req = (? S req) + (M? ) where S req is the total carried requests load due to nodes that are not overloaded and M is the number of overloaded nodes. The carried request load req;n of node n is equal to the oered request load req;n if req;n < R req and otherwise req;n = R req. The oered request load req;n is less than or equal to the oered (segment) load n and req;n < n when some requests are canceled. The bandwidth wastage W req on the request channel is given by: W req = (? )(? S req) + (M? ) Since the relative frequency with which a node successfully transmits a request determines the node's throughput on the data bus, the throughput for each node, except for the most upstream overloaded node A, is equal to the node's carried request load req;n. An overloaded node in CR-DQDB will continuously transmit segments downstream (bandwidth balancing is not applied to the data channel) and will only let an empty slot pass by if it receives a request from a node downstream. Since A is the most upstream node that is overloaded, it will transmit in all empty slots that are not requested by downstream nodes. The fraction of W req slots on the request bus does not contain requests (these request bits were \wasted" by the bandwidth balancing method applied to the request transmission) and therefore, we have that the total carried load for node A is equal to: A = R req + W req =? S req + (M? ) Thus, the throughputs of the nodes are equal using the CR-DQDB and the BB-DQDB protocols, except for the most upstream overloaded node A. The node A will have higher throughput in the CR-DQDB system. For example, if S req = 0 and there are M overloaded nodes, then all overloaded nodes, including the most upstream overloaded node A, will each transmit a fraction +(M?) of req = requests. The fraction of slots acquired by each overloaded node, except node A, is also? equal to req. A fraction of W req = +(M?) of all request bits are reset and this fraction of unclaimed slots will be used by node A. Node A's throughput is therefore equal to +(M?) and the network utilization is 00%. In contrast, using the BB-DQDB scheme, the fraction W req of the slots will remain unused. 3. Implementing the CR-DQDB Protocol Each CR-DQDB node contains two pairs of counters (RQ, CD) and (RQ RQ, CD RQ) for each bus. In addition, a node must also maintain a queue of messages, a counter for the number of queued requests, a counter for the number of requests-to-transmit-a-request and a bandwidth balancing trigger counter. Thus, a CR-DQDB node has three more counters than a BB- DQDB node. The CR-DQDB slot header is similar to the BB-DQDB slot header, except that it contains an additional RQRQ bit. The CR-DQDB protocol can use one of the reserve bits in the ACF octet in the BB-DQDB slot header to make a request-to-transmit-a-request. Figures 3, 4 and 5 present the details of the CR- DQDB protocol for transmitting RQRQ bits, request bits and segments, respectively. The procedure in Figure 3 assumes that a slot arrives on the data bus. Transmissions of RQRQ bits are not controlled and a node will 4

5 transmit an RQRQ bit when the number of RQRQ bits queued is greater than zero and the RQRQ bit in the slot is zero. When the RQRQ bit in the slot is one, then some node upstream wants to transmit a request and the RQ RQ counter is incremented to service the request-totransmit-a-request. if (RQRQ bit in slot header = 0) { if (Number_RQRQ_bits(data bus) > 0) { Transmit RQRQ bit in slot; Number_RQRQ_bits(data bus)--; { RQ_RQ(request bus)++; // Another node made a request to // transmit a request bit Figure 3: CR-DQDB procedure for transmitting RQRQ bits on the data bus The procedure in Figure 4 is used to transmit requests on the request bus. If the request bit in the slot is zero, the node will attempt to transmit a request if the number of requests queued for transmission is greater than zero. The request is sent if the CD RQ counter is zero and otherwise, the CD RQ counter is decremented by one. When the node succeeds in transmitting the request, the RQ Trigger variable is increased by one. When the value of RQ Trigger reaches RQ Threshold, it is reset to zero and the RQ RQ counter is articially incremented by one. The RQ Threshold variable plays a similar role as the variable in the bandwidth balancing method. If the node does not have any request to transmit, it decrements the RQ RQ counter by one when the request bit in the slot is zero and the RQ RQ counter is greater than zero. When the request bit in the slot is one, then a node downstream has made a request to transmit a segment and the RQ counter for the data bus is incremented by one to service the request. A segment is transmitted on the data bus using the procedure in Figure 5. It is similar to the one in Figure 4 for transmitting request bits, except the bandwidth balancing step has been omitted. The CD and RQ counters are used to coordinate the transmission of segments. Noif (Request bit in slot header = 0) then { if (Number_RQ_bits(request bus) > 0) then { if (CD_RQ(request bus) > 0) then { CD_RQ(request bus)--; // Count down for requests { Transmit request bit in slot; // Transmit request when RQ_CD = 0 Number_RQ_bits(request bus)--; RQ_Trigger(request bus)++; if (RQ_Trigger(request bus) = RQ_Threshold) then { RQ_Trigger(request bus) := 0; RQ_RQ(request bus)++; // Bandwidth balancing on requests if (Number_RQ_bits(request bus) > 0) then { CD_RQ(request bus) := RQ_RQ(request bus); RQ_RQ(request bus) := 0; Schedule an RQRQ on the data bus; { if (RQ_RQ(request bus) > 0) { RQ_RQ(request bus)--; // Maintain RQ_RQ counter { RQ(data bus)++; // Another node made a request // to transmit a segment Figure 4: CR-DQDB procedure for transmitting request bits on the request bus tice that all requests for a message are scheduled when the rst segment of the message is scheduled on the data bus. If the segments of message are transmitted before the requests for the same message, the remaining requests are canceled. If the node is idle, i.e., it has no segment to send, it will decrement the RQ counter if the slot is empty and its RQ counter is greater than zero. 4 Numerical Examples We have used simulation to study the performance of the CR-DQDB protocol in various network congurations and compared it with the results reported in [6] for 5

6 if (Busy bit in slot header = 0) { if (Number_Segments(data bus) > 0) { if (CD(data bus) > 0) { CD(data bus)--; // Count down for segments { Set busy bit in slot header; Transmit segment; Number_Segments(data bus)--; if (End of current message) { Cancel any remaining requests for this message; if (More messages) { Schedule all request bits of the next message for transmission on request bus; if (Number_Segments(data bus) > 0) { CD(data bus) := RQ(data bus); RQ(data bus):= 0; // Schedule next segment { if (RQ(data bus) > 0) { Decrement RQ(data bus) by one; // Maintain RQ counter Figure 5: CR-DQDB procedure for transmitting segments on the data bus Figure 6: Transient behavior of the CR-DQDB protocol under heavy load, upstream node starts rst that the rate in which the downstream node acquires its share of slots depends on the value of. A smaller value of results in a system that will reach the steady state more quickly. For instance, for = 0:8, the steady state is reached after only 700 slot times and for = 0:95, it is not reached until after 2500 slot times. The value of also aects the rate of convergence in the BB-DQDB protocol. the BB-DQDB method. Each slot consists of 53 octets. The transmission rate used is 50 Mbps and the time unit is the time to transmit one slot (a slot time). We begin the analysis by considering the transient behavior of a system consisting of two nodes separated by 38 slots. The same system using BB-DQDB was studied in [6]. The nodes transmit segments continuously downstream. In one experiment, the upstream node becomes active rst and in another, the node downstream starts the transmission rst. In the experiment in Figure 6, the upstream node has been busy for at least 38 slot times when the downstream node starts transmitting at time zero. Figure 6 shows the average throughput of the nodes over a 76 slot times interval at dierent points in time for equal to 0.8, 0.9 and The corresponding values for RQ Threshold are 4, 9 and 9, respectively. We see Figure 7: Transient behavior of the CR-DQDB protocol under heavy load, downstream node starts rst 6

7 The share of slots allocated to a node in the steady state is also dependent on the value of. The carried request load for both nodes is equal to req = + and the bandwidth wastage in the request channel is W req = +?. Consequently, the throughputs for nodes and 2 are equal to + and +, respectively. For example, the fraction of slots allocated to the upstream and downstream nodes in the steady state are and 0.444, and 0.53 and 0.487, for equal to 0.8 and 0.95, respectively. When is equal to 0.8, the fraction of requests made by each node is and 0. of the request bits are not used by any node. Node 2 transmits in the slots that it has reserved and node transmits in all slots that are not requested by node 2. Node will thus use in addition to its reserved slots (0.444 of all slots), all the unclaimed slots (0. of all slots). In contrast, the throughput of both nodes using BB-DQDB (see [6]), is equal to for equal to 0.8 and 0. of the slots are wasted. (The CR-DQDB scheme wastes 0. of the requests bits.) In the experiment in Figure 7 the downstream node starts transmitting prior to the upstream node. The steady state reached is the same one as in Figure 6 and does not depend on the order in which the nodes become active. The total throughput using BB-DQDB in the steady state are and 0.974, respectively, for equal 0.8 and 0.95 while the total throughput using CR- DQDB is always equal to one regardless of the value of. The manner in which the extra slots that are allocated using CR-DQDB is more evident in Figures 8 and 9. The system studied consists of the two nodes in Figure 7 and a third node. The RQ Threshold is equal to 4 to allow the system to respond quickly to changes in the oered load. The gures show the throughput of the nodes when the third node starts transmitting after the system in Figure 7 has reached the steady state. In Figure 8, the third node is located between the upstream and downstream nodes and in Figure 9, it is the most upstream node. We see than when there are two nodes active, the upstream node receives 0. more slots than Figure 8: Transient behavior of the CR-DQDB protocol under heavy load, third node located between upstream and downstream node, = 0:8 the down stream node. However, when three nodes are active, the two downstream nodes receive the same fraction of slots and the most upstream node receives an additional 0.08 of all slots. The number of extra slots is equal to the number of wasted slots in BB-DQDB. Figure 0 presents the result of a le transfer experiment using the CR-DQDB protocol. The system consists of three nodes and successive node are separated by 28 slots. We use = 0:8 to make the system highly responsive to changes. Initially the system is idle and each node will start a le transfer operation after a certain delay which is dierent for a dierent node. The downstream node rst starts transmitting a le of 8000 segments. The upstream node becomes active during the downstream node's transmission and transfers a le of 3000 segments. The middle node then begins a transmission of a le of 3000 segments while both nodes are active. At this point in time, all three nodes are active and the system allocates the same amount of bandwidth to the middle and downstream nodes. The upstream node uses the unreserved slots in addition to slots that it has reserved. When the upstream node nishes, the middle node becomes the most upstream node that is active and uses the unreserved portion of the slots. Af- 7

8 Figure 9: Transient behavior of the CR-DQDB protocol under heavy load, third node is most upstream node, = 0:8 ter the middle node completes the le transfer operation, the downstream node will use all the slots for its transmission. Table shows the message delay for each node. The elapsed time between the start and completion of the le transfer operations is exactly 4000 slot times which is the minimum time necessary to transfer the les. This is expected since no slot is wasted in CR-DQDB. The le transfer experiment is also performed using the BB-DQDB protocol. The transient behavior is shown in Figures and 2, and the delay of the transfers is given in Table. In Figure, we use = 0:95 to achieve high throughput. The resulting system is not very responsive as it takes more time to re-distribute the slots between the active nodes. As a result, node and 2 nish the le transfer after 8986 and 886 slot times, respectively. Compared to the CR-DQDB scheme, node and 2 experience an increase of 34% and 5% in delay, respectively. The transfer operations nish after 442 slots, which is 42 slots or 3% more than the minimum. In Figure 2 we use equal to 0.8 to achieve the same responsiveness as in Figure 0. However, a signicant fraction of the bandwidth is wasted and as a result, the le transfer operations terminates only after 5999 slot times which is 4% more than required. The individual Figure 0: File transfer using Controlled Request DQDB with = 0:8 nodes also experience longer delay in the transfer operations than in the CR-DQDB system. Delay (in slot times) Upstr. Middle Downstr. Protocol node node node CR-DQDB BB-DQDB BB-DQDB Table : Delay in the le transfer experiments In Table 2, we compare the average message delay in various CR-DQDB and BB-DQDB systems. The delay values for the BB-DQDB systems in the table were obtained from [6]. The systems studied consist of two nodes separated by 0 or 50 slots, and is equal to 0.9. The nodes are numbered as and 2 and are located upstream and downstream, respectively. The arrival processes to nodes and 2 are Poisson with rates and 2 messages per slot time and the average message lengths are and 2, respectively. The four right most columns in the table contain the average message delay (the unit is one slot time) for the nodes using CR-DQDB and BB- DQDB protocols. 8

9 Figure : File transfer using Bandwidth Balanced DQDB with = 0:95 Figure 2: File transfer using Bandwidth Balanced DQDB with = 0:8 We have considered ten dierent systems numbered from A to J. In each system, the total oered load is 0.8 times the system capacity. We can see in the table that in all cases the message delay of the heavier loaded node is smaller when the CR-DQDB protocol is used. The lighter loaded node also has better message delay in a majority of the cases, but in two cases (cases B and J), it experiences a higher delay. Using the BB- DQDB scheme, node will occasionally leave slots empty which node 2 can use immediately. If the message that node 2 is transmitting is short, node 2 may be able to transmit the entire message using the empty slots left by node and the resulting message delay is small. On the other hand, when node is transmitting a long message using the CR-DQDB protocol, it will not leave any slots empty while node 2 is idle. When node 2 receives a short message in this case, it can transmit the rst segment of the message only after node has received node 2's request and allowed an empty slot to pass by. This initial delay increases with the distance between nodes and 2. For short messages, this delay can increase the message transmission time substantially and the delay for short messages using CR-DQDB may be higher than using BB- DQDB. For example, in case J, node 2 is located far away from the upstream node and transmits very short messages. The average message delay for node 2 is higher in CR-DQDB than in BB-DQDB. Notice that in case I where the nodes are located near each other, the message delay of node 2 is the same in both schemes. Node does not experience any initial delay when it transmits short messages because all slots are empty when they rst arrive at node. Consequently, in cases G and H, node 's delay using CR-DQDB is lower than BB-DQDB. Overall, we can see a signicant improvement in message delay when the CR-DQDB protocol is used. 5 Concluding Remarks We have presented the Controlled Request DQDB protocol and analyzed its performance in various system congurations. The transmission of requests in the Controlled Request scheme is controlled by the same counter mechanism that is used to coordinate transmissions of segments. The Controlled Request DQDB scheme is more complex than the Bandwidth Balanced DQDB and requires three additional counters per node per bus. The Bandwidth Balancing technique is used to refrain nodes from transmitting requests continuously. The nodes will share the request channel fairly and as a result, the slots are divided (almost) evenly among the nodes. The Controlled Request scheme is not completely fair as the most upstream node is allocated more slots than all other 9

10 System Topology Case 2 / /2 Sep. A B C D E F G H I J Delay Characteristics CR-DQDB BB-DQDB Case Delay Delay 2 Delay Delay 2 A B C D E F G H I J Table 2: Average delay in CR-DQDB and BB-DQDB systems, = 0:9 nodes. The number of extra slots that the most upstream node receives is equal to the number of wasted slots in DQDB with Bandwidth Balancing. A simulation study showed that the Controlled Request scheme achieves 00% throughput and is highly responsive to changes in the oered load. The study also showed that the message delay in DQDB systems using Controlled Request is better than that in systems using Bandwidth Balancing. References [] R. M. Newman, Z. L. Budrikis, and J. L. Hullett, \The qpsx man," IEEE Comm., vol. 26, pp. 20{28, April 988. [2] IEEE Working Group, Proposed IEEE Standard 802.6: Distributed Queue Dual Bus Subnetwork of a Metropolitan Area Network. IEEE, Draft D4, July 20, 990. [3] J. W. Wong, \Throughput of dqdb networks under heavy load," in EFOC/LAN-89, (Amsterdam, The Netherlands), pp. 4{6, 989. [4] M. Conti, E. Gregori, and L. Lenzini, \Dqdb meia access control protocol: Performance evaluation and unfairness analysis," in 3rd IEEE workshop on MAN's, (San Diego, Calif.), pp. 375{408, March 989. [5] M. Zukerman and P. Potter, \The dqdb protocol and its performance under overload trac conditions," in ITC Specialist Seminar, Paper No. 6.4, (Adelaide, Australia), 989. [6] E. L. Hahne, A. K. Choudhury, and N. F. Maxemchuk, \Improving the fairness of distributed-queuedual-bus networks," in InfoCom 90, pp. 75{84, IEEE, 990. [7] P. Tran-gia and T. Stock, \Approximate performance analysis of the dqdb access protocol," in ITC Specialist Seminar, Paper No. 6., (Adelaide, Australia), 989. [8] C. Bisdikian, \Waiting time analysis in a single buer dqdb (802.6) network," in InfoCom 90, pp. 60{66, IEEE, 989. [9] E. Y. Huang and L. F. Merakos, \On the Access Fairness of the DQDB MAN Protocol," in Proceedings of the 9th IEEE 990 Intl. Phoenix Conf. on Computres & Communications, pp. 556{559, IEEE, 990. [0] B. Mukherjee and S. Banerjee, \Alternative Strategies for Improving the Fiarness in and an Analytical Model of DQDB Networks," in InfoCom 9, pp. 879{ 888, IEEE, 99. 0