Reliable transmission of data over a semi-FIFO routing layer

and

ISDN SYSTEMS ELSEVIER Computer Networks and ISDN Systems 27 (1995) 1633-1649

Reliable transmission of data over a semi-FIFO routing layer Reuven Cohen a,*, Yoram Ofek b

a Department of Computer Science, Technion, Haifa 32000, Israel b IBM 7: J. Watson Research Center. Yorktown Heights, NY 10598, USA

Accepted 22 November 1994

Abstract

In computer networks there is usually a trade-off between the performance and implementation complexity of the routing protocol, and those of the protocol for reliable transmission of data. Often, the routing protocol can perform better if it is not required to retain the FIFO order of the routed data units. However, in such a case the protocol for reliable transmission of data has to maintain many logical timers and to have accurate estimate of the round trip delay.

The paper introduces a new notion: semi-FIFO service, which means that the routing layer retains the FIFO order in part. The paper shows that sometimes a non-FIFO routing layer may provide for semi-FIFO service, without substantial changes in the routing concept. Then, the paper proposes a new protocol for reliable transmission of data over an unreliable semi-FIFO routing layer. The protocol uses only one logical timer and does not require an estimate of the round trip delay in order to operate with full capacity. Therefore, the contribution of the paper is eliminating the deficiencies associated with non-FIFO routing schemes that may offer semi-FlFO service.

Keywords: Routing protocols; Semi-FIFO; Protocols for reliable transmission of data; TCP

1. Introduction

In recent years, with the advance of the fiber-optic technology, thle error rate of communication channels has significantly decreased. However, data networks are still unreliable: data units sent by the stations can be lost, corrupted or received out of order. Therefore, end-to-end protocols are required in order to ensure that all the messages sent by a source will be received by the destination in the same order, with no loss, duplication or error. These are protocols for reliable transmission of data.

Protocols for reliable transmission of data are usually implemented in the DLC (Data Link Control)

* Corresponding author

layer and in the Transport layer [2,4,3,6,11,10,14]. In those networks where the access to the media is con- trolled by a MAC (Media Access Control) layer, like the token-ring, ethernet and FDDI, the protocol in the DLC layer that ensures reliable transmission of data is referred to as LLC (logical link control) [ 73. Re- gardless of the layer where the protocol for reliable transmission of data is implemented, its complexity and efficiency depend on the services provided by the underlying layer. In particular, protocols for reliable transmission of data that sit on a layer that retains the FIFO (First In First Out) order of data units can be more efficient and less complex than protocols whose underlying layer does not retain FIFO.

Since this paper emerges from our efforts to design an LLC protocol for a network that performs routing

0169-7552/95/!609.50 @ 1995 Elsevier Science B.V. All rights reserved SSD10169-7552(94)00107-3

1634 R. Cohen, L Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

(4

(b) Fig. 1. FIFO and non-FIFO routing. (a) The MAC layer retains FIFO. (b) The MAC layer does not retain FIFO.

in the MAC layer (without keeping FIFO), the protocol for reliable transmission of data is referred in the following to as an LLC protocol. However, the ideas presented in the paper are applicable also to Trans- port layer protocols of networks whose routing is per- formed in the Network layer.

The MAC layer is said to retain the FIFO order if the frames transmitted by some station to the other one do not pass each other. For example, Fig. 1 (a) shows a transmission of 5 LLC-PDUs (the Proto- col Data Units sent by the LLC) in 6 MAC frames when the MAC layer retains FIFO. The sending LLC sends LLC-PDU( 1) through LLC-PDU(5) and then resends LLC-PDU(4), since it is informed by the receiving LLC that this LLC-PDU has not been received. The fact that LLC-PDU( 5) is received by the receiving LLC before LLC-PDU(4) does not contradict the fact that the MAC layer retains FIFO. This is because FIFO of the MAC layer does not relate to LLC-PDUs, but to MAC frames, and, as the figure shows, frames do not pass each other. In Fig. 1 (b), the second frame is received by the destination MAC after the third one. Therefore, regardless of the LLC-PDU encapsulated in this frame, the MAC layer in this case does not retain FIFO.

The MAC layer in 802.X/FDDI Local Area Net- works (LANs) retains FIFO. However, MAC FIFO is not guaranteed in LANs with an arbitrary topology [8,9,12]. In fact, even if several 802.X/FDDI LANs are connected in the MAC layer by bridges to form a bridged-LAN, MAC FIFO can be violated. There are two standards bridged LANs: transparent spanning tree and source routing. In order to ensure

Fig. 2. Network example.

MAC FIFO, bridges that support the transparent spanning tree approach must discard frames whenever the tree changes. In order to ensure MAC FIFO in a source routing bridged network, the end stations are required to use only one route per each logical connection. This restriction is demonstrated in Fig. 2. Suppose that station s has to send a lot of data to d, and that i, j, k and I are source routing bridges. If MAC FIFO was not required, s would be able to use routes s - i - j - d and s - k - I- d simultaneously. However, since the LLC used in bridged LANs [ 71 requires FIFO, s must choose only one route over which all its frames to d will be routed.

The paper introduces a new notion: semi-FIFO service, which means that FIFO is retained in part. The paper shows that sometimes it is easy for a non-FIFO routing layer to provide for semi-FIFO service. Then, the paper proposes a new LLC protocol for reliable transmission of data over an unreliable semi-FIFO layer. The new protocol uses only one logical timer and does not need an estimate of the round trip delay in order to operate with maximum capacity. Therefore, the contribution of the paper is eliminating these two deficiencies associated with a non-FIFO MAC layer, when such a layer provides for semi-FIFO service.

The rest of the paper is organized as follows. Sec- tion 2 introduces the model and terminology used in the paper. Section 3 explains why FIFO routing facilitates the design and implementation of the LLC protocol. Section 4 explains what semi-FIFO means. In order to demonstrate how semi-FIFO can be provided by a non-FIFO layer, we introduce the MetaNet. This network uses deflection routing and therefore does not retain FIFO. However, a simple modification in the routing scheme can ensure semi-FIFO routing. Sec- tion 5 presents the new protocol for reliable transmission of data over an unreliable semi-FIFO layer. The correctness proof for this protocol is given in the Ap-

R. Cohen, I! Ojek/Computer Networks and ISDN Systems 27 (1995) 1633-1649 1635

pendix. Section 6 deals with timing issues related to the new protocol, and Section 7 concludes the paper.

2. Model and terminology

Figure 3 shows the protocol reference model considered in the paper. The top layer will be considered as the user layer or the upper layer. The intermediate layer, where the protocol for reliable transmission of data is implemented, will be referred to as LLC. The lower layer, over which the LLC is implemented, will be referred to as the routing layer or the underlying layer. For simplicity, we assume that information is sent in one direction only: from the source to the destination. The user layer at the source will be referred to as the sending user and its peer as the receiving user. The LLC layer at the source is the sending LLC, and its peer is the receiving LLC.

The sending user sends data to the receiving user in the form of messages. Every message is submitted to the sending LLC. The sending LLC and the receiving LLC use an LLC protocol in order to ensure that all the messages sent by the sending user will be delivered to the receiving user in the same order, with no loss or duplication. Each message of the sending user is encapsulated by the sending LLC in an Information LLC-PDU, and gets a sequence number. The LLC sends a PDU by submitting it to the underlying layer for transmission.

We distinguish between LLC-PDUs that contain messages of the user layer, and those that contain only control signals of the LLC protocol. The former will be referred to as I-PDUs (Information LLC-PDUs) , and the latter as S-PDUs (Supervisory LLC-PDUs) . I-PDUs are sent by the sending LLC only, whereas S-PDUs are sent in both directions.

In the intermediate nodes only the routing layer is involved: a frame is received and transmitted into the network after a routing decision is made. In the tradi- tional LANs these nodes are bridges. In the new gen- eration ATM and non-ATM switch-based LANs, these nodes are routing switches.

Recall that by FIFO routing we mean that frames do not pass e,ach other while traveling in the network from the sending LLC to the receiving LLC or vice versa. However, frames can be lost during their routing. Thus, FIFO routing means that PDUs submitted

by the sending LLC to its MAC and are not lost during the routing from the source to the destination are delivered to the receiving LLC in the same ordel; and vice versa As shown in Fig. 1 (a), FIFO in this paper is related to frames containing LLC-PDUs, and not to messages. This is the task of the LLC to ensure that all the messages submitted by the sending user to the sending LLC are delivered by the receiving LLC to the receiving user in their original order, with no gaps, or duplications.

3. Why FIFO is considered important?

Two basic mechanisms are used by protocols that ensure reliable transmission of data: (a) responses from the receiving LLC to the sending LLC, sent in the form of S-PDUs; (b) retransmissions by the sending LLC of considered lost I-PDUs.

In order to understand why an underlying layer that retains FIFO facilitates the design of the LLC protocol, consider such a protocol between a source s and a destination d. Suppose that I-PDU( 1) through I- PDU( i - 1) have been sent by the LLC of s and received by the LLC of d properly. The next PDU sent by s is PDU number i. Consider now the following cases at the receiving LLC:

( 1) I-PDU( i) is received with no error. (2) I-PDU( i) is not received since the frame con-

taining this I-PDU has been lost. Moreover, no I-PDU(j) where j > i is received by the receiving LLC after I-PDU( i) i , either because I- PDU(i) was the last to be sent or because all successive I-PDUs are lost as well. This implies that I-PDU( i - 1) was the last to be received by the receiving LLC.

(3) I-PDU( i) is not received; however, the receiving LLC receives I-PDU(j), where j > i.

Note that the case where I-PDU( i) is received with an error is equivalent to the second case. Such an I-PDU is discarded and considered as lost.

’ It will be convenient to assume at this stage that the sequence number space is unbounded. Therefore, if the receiving LLC receives I-PDU(i) and I-PDU(j), where j > i, it knows that I- PDU(i) contains a message that should be delivered before the message contained in I-PDU( j )

1636 R. Cohen. I! OfeklComputer Networks and ISDN System 27 (1995) 1633-1649

source destination

user messages sending user .-----------------------------.----------------------------,receiving user user (upper layer) (upper layer)

Information LLC-PDUs (I-PDUs) ._________________._____________________------------------- LLC sending LLC Supervisory LLC-PDUs (S-PDUs) receiving LLC LLC ---__________--_._______________________-----------------

routing frames intermediate frames intermediate frames

. c node 4 l . node . c routing

Fig. 3. Model and terminology.

RECEIVING LLC

Fig. 4. The last sent I-PDU is lost.

The first case can be easily handled by the receiving LLC, whether the underlying layer retains FIFO or not. The receiving LLC should simply send an AC- Knowledgment S-PDU (called ACK) , confirming the receipt of I-PDU( i) . The second case is more diffi- cult, because the receiving LLC is not able to know that I-PDU(i - 1) was not the last to be sent. There- fore, whether the underlying layer retains FIFO or not, the sending LLC must maintain a timer, called rimer(lusr), in order to recover from the loss of the lust I-PDU (or I-PDUs). Whenever it sends an I-PDU, the sending LLC should set this timer to T, where T is the estimated round trip delay. When timer(last) times out, the sending LLC should resend all I-PDUs for which ACK has not been received. Consequently, in our example, T seconds after the sending LLC sends I-PDU( i), timetflusr) times out and another copy of I-PDU( i) will be sent (see Fig. 4). Another way to recover from the loss of the last sent PDU is to have ACK PDUs periodically sent by the receiver, indicating the status of the receiving window. An efficient implementation of such a solution requires a timer and a good estimate of the round-trip delay at the receiver.

However, usually the lost I-PDU is not the last to be sent. This brings us to the third case, which is much

more common than the previous one. This is also the case where the differences between FIFO and non- FIFO underlying layers show. First, suppose that the underlying layer retains FIFO. Therefore, when the receiving LLC receives I-PDU(j) before having received I-PDU( i), where i < j, it knows that I-PDU( i) has been sent and lost. Subsequently, the receiving LLC may send a NACK( i), informing the sending LLC that I-PDU(I’) should be resent. No timer is involved in this scenario.

Next, suppose the underlying layer does not retain FIFO. When the receiving LLC receives I-PDU( j), it knows that I-PDU( i) has been sent. However, it is not able to know whether this I-PDU has been lost or it just experiences a longer delay than I-PDU(j). Assuming the variance of the round trip delay is high, namely, with high probability an I-PDU can be received before previously sent I-PDUs, the approach taken by the TCP [2] (a Transport layer protocol whose underlying routing layer, the IP, does not retain FIFO), is reasonable: the receiving LLC keeps waiting for I- PDU( i) . The question arising now is what happens if I-PDU(I’) will never arrive. If the sending LLC uses only one timer, the one which is necessary in those cases where the lost data unit is the last to be sent

R. Cohen, Y Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649 1637

@art t fmer

restart timer

. . . I-- T sec.1

restart timer %t

rTsec.l restart restart

timer (i + 11 timer i

timer i times-out res art

timer i + 62)

(b)

fig. 5. The recovery from a loss of an I-PDU. (a) One timer. (b) Multiple timers.

(timer(last)), it will recognize the loss of I-PDU( i) only after having sent all the I-PDUs in its window.

For example, suppose that the width of the sending LLC window is 64, which means that the sending LLC may send up to 64 I-PDUs before receiving any acknowledgment, and consider Fig. 5(a). The sending LLC sends 1:PDU( i) and restarts its timer. I-PDU( i) is lost, but before the timer times out another I-PDU (I-PDU( i + 1) ) is sent and the timer is restarted. The timer is restarted again and again, since the sending LLC may send up to 62 I-PDUs before receiving the ACK for I-PDU( i) . I-PDU( i + 62) is the last one the sending LLC is allowed to send. Therefore, only T seconds after the transmission of this I-PDU timerflast) times out, and the sending LLC will resend I-PDU( i) .

In order to prevent this long delay before retransmissions, the: sending TCP [2] uses a separate timer for every outstanding I-PDU (i.e, an I-PDU for which an acknowledgment has not been received yet). When I-PDU(i) is sent, timer(i) is reset to T. This timer is not restarted when subsequent I-PDUs are sent, as

shown in Fig. 5(b). Therefore, if I-PDU( i) is lost, timer(i) times out T seconds after the transmission of I-PDU( i) , rather than T seconds after the transmission of I-PDU(i+ 62).

Applying this TCP approach in the LLC protocol would result in two major drawbacks. First, the man- agement of many logical timers in the LLC, using one physical timer, requires a lot of processing, and may become the bottleneck of the sending LLC, especially in high-speed LANs. The second problem is that this solution requires a good estimate of the round trip delay. This is because premature time outs would result in unnecessary retransmissions, whereas late time outs would yield long delay before retransmissions. It is true that for the maintenance of timer(last) an estimated round trip delay is required even if the routing layer retains FIFO. However, as explained above this timer is used only in those rare cases where the lost data unit is the last to be sent. Therefore, if the sending LLC sets its timer to a value greater than the maximum possible round trip delay, unnecessary re-

1638 R. Cohen, K Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

transmissions will be avoided, and the impact of the long recovery on the performance of the LLC protocol will be insignificant.

The ability of the sending LLC to find a good estimate of the round trip delay depends on the network architecture and the MAC protocol. Generally, one may distinguish between the following cases: ( 1) The round trip delay is stable; namely, PDUs

sent almost in the same time interval encounter similar delay.

first and the second PDUs, whereas the last PDU is also the last to be delivered to the receiving LLC. The first, second and fourth PDUs, however, are delivered to the receiving LLC out of order.

(2) The round trip delay changes from one PDU to another.

In the first case, the sending LLC may execute some algorithm in order to measure the round trip delay and to adjust its timers accordingly. This is in fact what the sending TCP does [2]. However, as explained in [ 151, measuring the round trip delay is not a triv- ial task that may fail even in a stable environment. Unfortunately, most of the networks whose underlying (MAC) layer does not retain FIFO fall into the second category [ 8,9,12]. For example, in networks that use deflection routing the round trip delay drasti- cally changes from one PDU to another, thus a good estimate of the round trip delay is unlikely to exist.

It turns out that sometimes a non-FIFO underlying layer may easily offer semi-FIFO service. For example, consider again a source routing bridged-LAN, and suppose that multiple routes can be used for one connection. Therefore, when the MAC layer at some source s receives from its LLC a PDU for transmission to d, it may choose any route from a predefined set R(s, d) of routes between s and d. The intermediate bridges route a received PDU according to the information in the routing field. Obviously, this approach would violate FIFO. For instance, consider Fig. 2 and let R( s, d) contain the routes s - i - j - d and s - k - 2 - d. If the first PDU sent by s to d is routed through the route s - i - j - d, and the second one is routed through the parallel route s - k - 1 - d which is less loaded, the second PDU can be received by the receiving MAC and delivered to the receiving LLC before the first one.

The conclusion of this section is that in order to perform well when the underlying layer retains FIFO, the sending LLC should maintain only one timer and should know only an upper bound of the round trip delay. If, however, the underlying layer does not retain FIFO, the sending LLC should maintain a timer for every outstanding I-PDU, and should have a good estimate of the round trip delay.

4. Semi-FIFO service

Semi-FIFO means that FIFO is provided in part. When the LLC layer submits an LLC-PDU to the underlying layer, it indicates whether FIFO is required or not for that specific PDU. If FIFO is not required, the PDU can be delivered to the receiving LLC out of order. If FIFO is, required, the underlying layer at the destination must submit the PDU to the receiving LLC after all previously sent PDUs.

Now, consider the following change in this source routing approach, that would yield semi-FIFO service. When the LLC of s submits to its underlying layer a PDU and requires a FIFO service for this PDU, the underlying layer transmits a copy of the PDU on every path p E R( s, d) instead of on only one path. When the underlying layer at the destination receives a PDU for which FIFO has not been required (a single bit in the PDU header may indicate whether FIFO has been required for this PDU or not), it immediately delivers the PDU to its LLC layer. However, if a PDU for which FIFO has been required is received, the underlying layer at the destination waits until a copy of this PDU is received on every other path in R(s, d) and just then delivers one copy to its LLC.

This example shows that the transmission of PDUs in “FIFO mode” by a non-FIFO underlying layer would cost more bandwidth than the transmission in “non-FIFO mode”. However, if the PDUs for which FIFO is required are much shorter than those for which FIFO is not required, the overhead bandwidth will be negligible.

For example, consider Fig. 6. The sending LLC In the following, we briefly present the MetaNet, a submits 5 PDUs to the underlying layer, but requires LAN with an arbitrary topology that uses deflection FIFO only for the third and the last one. Therefore, the routing. We will show how the MetaNet routing layer third PDU is delivered to the receiving LLC after the may provide semi-FLPO service to its LLC.

R. Cohen. E Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

SENDING LLC non-FIFO non-FIFO FIFO non-FIFO FIFO

RECEIVING LLC

Fig. 6. Semi-FIFO routing.

1639

MetaNet is .an arbitrary topology LAN [9] whose routing layer does not retain FIFO. Routing is based on a virtual embedding of a unidirectional ring in the network. The ring provides global sense of direction, and ensures that MAC frames always reach their des- tinations.

The bidirectional links of MetaNet are ordered such that a unidirectional ring that traverses each link in each direction exactly once is formed. For example, consider the network in Fig. 7(a). Suppose that the Euler Tour on this network goes from a to b, back to a, then to c, to b again, back to c, to d, to b in the third time, and finally back to d, c and a. The ring defined by this tour is shown in Fig. 7(b). Note that the number of logical nodes representing a physical node is equal to the degree of that node in the original network. For instance, node a is represented twice (us and ~2) whereas node b is represented 3 times (bl, bq and tq) . The identity given to each logical node consists of two parts. The first part indicates the identity of the physical node. The other part is a global sequence number given to the logical nodes according to their relative location on the embedded ring. These numbers are used for routing.

The main idea behind MetaNet is achieving the lossless-ness property of ring LANs on the arbitrary topology network. There are several access control protocols for ring LANs that enable multiple simul- taneous transmissions with no loss due to congestion. These protocols use the bufSer insertion concepts, and each of them can be used on the embedded ring of MetaNet.

Consider a MAC frame at node a whose destination is d. The frame enters the ring through the logical

Fig. 7. MetaNet example. (a) An arbitrary topology network. (b) An embedded ring.

node of a from which the distance on the ring to a logical node of d is the shortest. In our case the source virtual node is u2 and the destination is dg. When the MAC rules allows UP to transmit a new frame into the ring, it transmits this frame. Using the global sequence numbers, c knows that it can transmit the frame either to b4 or to dg (since the sequence number of each of them is smaller than the one of the destination). The second choice is better, since d is the destination, but the virtual ring ensures that a frame received by cg can be forwarded with no delay only to b4. Therefore, c checks whether the output buffer of cg is empty or not. If it is empty, the frame is deflected from cs to cs. Due to this deflection, node 64 in the embedded ring is skipped and the destination d becomes closer. If, however, the buffer of cs contains another frame, that has been received on the ring from b4, the frame is transmitted by cs to b4, and then continues on the virtual ring through cs to de.

The routing rules are, therefore, as follows. A transmitted frame continues along the virtual ring with no delay until reaching the virtual destination node. How- ever, if the frame is received by some virtual node

1640 R. Cohen, E Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

xi when another virtual node xj in the same physical transmissions due to premature time-outs aggra- node x is both idle and closer to a destination virtual vate the congestion, and in high-speed networks, node, the frame is deflected from xi to xj, and contin- where the processing speed of the receiving LLC ues towards the destination. cannot match the rate of the incoming PDUs.

Obviously, this routing approach does not retain FIFO. If the first frame sent by a to d is not deflected from cl to ~2, whereas the second frame is deflected because c2 becomes idle, the second frame may be received by d, before the first frame. Nevertheless, semi- FIFO can be provided in the following way. When the underlying layer at the source receives from its LLC an LLC-PDU for which FIFO is required, it marks the header of the frame containing this PDU as an “unde- t&table frame”. Such a frame will traverse the entire portion of the ring between the source an the destination virtual nodes, without being deflected. Thus, it will be received by the destination after any previously sent frame. We can see here again that those frames for which FIFO is required consume more bandwidth than frames for which FIFO is not required.

Except the SSCOP protocol, to which we shall refer later, we know of no other protocol for reliable transmission of data over non-FIFO layer that guarantees Property 4. Moreover, we know of no other protocol for which Properties 1-3 hold together.

The retransmission mechanism used by the protocol is selective-repeat. Due to the non-FIFO routing of I-PDUs, the latter must be reordered at the receiving LLC. This means that buffers and processing time for reordering, which are the overhead associated with the selective-repeat approach, should be paid whether the retransmission mechanism is go-back-N or selective- repeat. Therefore, we prefer using selective-repeat, that reduces the number of unnecessary retransmissions.

However, selective-repeat is a necessary but insuffi- cient condition for ensuring Property 4. For instance, suppose that the receiving LLC informs the sending LLC that I-PDU(i) has been lost. Suppose also that the receiving LLC waits some time, but does not receive I-PDU(i) though the latter has been resent. If the receiving LLC asks the sending LLC again to resend I-PDU(i), an unnecessary retransmission will take place.

5. The new protocol

This section presents a new LLC protocol for reliable transmission of data over an unreliable semi-FIFO MAC layer. This protocol does not require FIFO for I-PDUs, but only for S-PDU (which are considerably shorter). The main properties of the new protocol are as follows:

(1)

(2)

(3)

(4)

The protocol ensures that all the messages sent by the sending user will be delivered to the receiving user in their original order, with no loss or duplication. The sending LLC needs only one timer per connection, rather than one logical timer for each outstanding PDU. No timer is required at the receiving LLC. Neither the source nor the destination are required to estimate the round trip delay or an upper bound of the round trip delay. The protocol ensures that I-PDUs will never be resent by the sending LLC unnecessarily. This means that if the sending LLC resends an I- PDU, all previous copies of this I-PDU have been lost. This property may be of importance in congested networks, where unnecessary re-

5. I. Infoml description of the protocol

The LLC protocol uses three types of Supervisory LLC-PDUs (S-PDUs) :

ACK-RJZQ: Sent by the sending LLC periodically every T seconds. By sending an ACK-REQ, the sending LLC requests the receiving LLC to confirm the receipt of previously sent I-PDUs.

ACK, NACK: A positive/negative acknowledgment, sent by the receiving LLC in response to an ACK-REQ.

All these S-PDUs should be sent by the underlying layer in a FIFO mode. Since they are much shorter than the I-PDUs, which can be sent in a non-FIFO mode, in many cases the overhead for supporting FIFO by a non-FIFO underlying layer will be negligible.

R. Cohen, Y Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649 1641

SENDINGLLC t1 t3 t5 t7

t2 t4 t6 t8

RECEIVING LLC Fig. 8. Example of the protocol.

The sending LLC sends I-PDUs from its window. Every T seconds its timer times out, and the sending LLC sends an ACK-REQ, asking the receiving LLC to acknowledge the receipt of the last sent I-PDUs. Section 6 explains how T should be determined. A possible scenario is shown in Fig. 8, assuming the width of the sending LLC window is 64. The sending LLC starts sending I-PDUs from its window until its timer times out, at time tt, indicating that an ACK- REQ should be sent. Since this happens after the sending LLC has sent I-PDU (0) through I-PDU( 20), the ACK-REQ sent by the sending LLC at tt contains the number 20. After sending an ACK-REQ, the sending LLC does not wait for an ACK, but it keeps sending I-PDUs from its window. This is because its window is not empty yet.

The receiving LLC may receive I-PDU( 0) through I-PDU(20) out of order. However, due to the semi- FIFO property, when the receiving LLC receives at t2 ACKREQ(20), it knows that any I-PDU( i), where 0 5 i 5 20, that has not been received so far, was lost. In our example it is assumed that no I-PDU was lost. Therefore, the receiving LLC sends an ACK( 20)) ap- proving the receipt of all I-PDUs up to I-PDU(20). When the sending LLC receives this ACK, it advances its window 21 steps.

During [t I, tg ] the sending LLC sends I-PDU( 21) through I-PDU(30) and at ts, when its timer times out again, it sends ACKREQ(30). Suppose that I- PDU( 27) is lost. Therefore, when the receiving LLC receives at t,r the ACK-REQ( 30), it responds with NACK( 27). When the sending LLC receives this NACK, at t7, it resends I-PDU( 27).

Like every protocol that uses negative acknowledg- ments, the plrotocol as described so far may cause

unnecessary retransmissions of I-PDUs. In order to demonstrate this problem, suppose that the third ACK- REQ (ACKREQ(42)) is sent by the sending LLC at t5, namely before the NACK(27) is received (as shown in Fig. 8). Therefore, this ACK-REQ can be received by the receiving LLC before fs, the time when the resent copy of I-PDU( 27) is received (note, however, that due to the non-FIFO of the I-PDUs, ACK- REQ( 42) can be passed by I-PDU( 27) ) . This ACK- REQ informs the receiving LLC that it should have received all I-PDUs up to I-PDU( 42). However, since I-PDU(27) was lost, and the resent copy of this I- PDU has not been received yet, the receiving LLC responds with another NACK( 27)) causing an unnecessary third transmission of I-PDU( 27).

The problem of unnecessary retransmissions happens because the protocol allows the sending LLC to send an ACK-REQ before receiving an ACK or a NACK to the previous ACK-REQ. A possible solution could be, therefore, to ask the sending LLC to wait for an ACK or a NACK after every ACK-REQ it sends, before sending another ACK-REQ. If this approach was used in the example of Fig. 8, the sending LLC would send ACKREQ(42) only after having received the NACK( 27) and resent I-PDU( 27). Consequently, the second copy of I-PDU(27) would be received before ACKREQ(42), so the receiving LLC would respond to the ACKREQ(42) with an ACK rather than with a NACK( 27).

However, asking the sending LLC to wait for a response to the last ACK-REQ before sending a new one would result in two significant deficiencies. First, this would complicate the sending LLC algorithm and require a mechanism for detecting the loss of ACK- REQs. Second, the width of the sending LLC window

1642 R. Cohen, k: Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

should almost be doubled in order to prevent the sending LLC from wasting time on waits. This is shown in Section 6.

In order to prevent unnecessary retransmissions without preventing multiple outstanding ACK-REQs, a single acknowledgment bit is employed in the sending LLC memory, as well as in the ACK-REQ and NACK I-PDUs. The operation of this bit is demonstrated in Fig. 9. Suppose that at time tl, when the sending LLC sends the first ACK-RFQ, the value of its acknowledgment bit is 0. The sending LLC appends the value of the acknowledgment bit to the ACK-REQ. If the receiving LLC responds to the ACK-REQ with a NACK, it copies the response bit from the ACK-REQ to the NACK. This is indeed the case at time t4. When the sending LLC receives a NACK, it compares the acknowledgment bit in the NACK with the bit in its memory. If they are equal, as happens at t7, it processes the NACK (i.e. resends I-PDUs) and reverses the value of its local bit. If the received bit and the incoming one are different, as happens at t9, the sending LLC discards the NACK (resends no I-PDU) and does not change the value of its local bit.

This mechanism ensures that the sending LLC processes only those NACKs sent in response to the last ACK-REQ. Since the Semi-FIFO property implies that the last ACK-REQ must be received after all previously sent (and not lost) I-PDUs, there will be no unnecessary retransmissions.

The Service Specific Connection Oriented Proto- col (SSCOP) [ 51 is a peer-to-peer protocol used by SAAL (signaling ATM Adaptation Layer) in order to ensure reliable transmission of signaling messages in ATM. It turns out that there are some similarities between the protocol presented in this paper and SS- COP2. In particular, the SSCOP sender uses POLL messages in order to request status information from the peer SSCOP Upon receiving a POLL message, the receiver should respond with a STAT message. The POLL messages, which are equivalent to the ACK- RFQ messages of our protocol, carry the sequence number of the last sent I-PDU. In addition, POLL messages have sequence numbers of their own (modulo 224). These sequence numbers are used in order to

2 We thank the reviewer who brought this interesting fact to our

attention.

avoid unnecessary retransmission of I-PDUs (referred to as SD-PDUs in [ 51). SSCOP was not designed to work in a semi-FIFO environment, because a signaling ATM VC, and in fact every ATM VC, retains the FIFO order of messages. However, due to its simi- larity to the protocol presented in this paper, SSCOP with small modifications can be applied to semi-FIFO environment.

5.2. Formal description of the protocol

Let the sequence number space be 0. . . N - 1, and the width of the sending LLC and receiving LLC windows, as negotiated during connection set-up, be W.

The sending LLC manages 4 pointers: PSI, PSZ, Ps3, and Ps4. Each pointer points on a number in the sequence number space. The pointer arithmetic is modulo N. The pointers define 3 sub-windows, called W’s,, Ws2, and Ws3. Each sub-window Wsi consists of a sequence of I-PDUs whose sequence numbers are between Psi and Psi+] - 1. The purpose of the each sub- window is as follows:

l Sub-window Wq contains sent I-PDUs for which ACK-REQ was sent, but ACK or NACK have not been received yet.

l Sub-window Ws2 contains sent I-PDUs for which an ACK-REQ has not been sent yet.

l Sub-window Ws3 contains I-PDUs the sending LLC has to send.

The sending LLC window, Ws, is defined as WsiWs, U

ws2 u ws3. Upon initialization, the sending LLC sets PSI, Ps:!

and Ps3 to 0. Ps4 is set to W, and the first W messages submitted by the upper layer are placed in sub- window Ws3 as I-PDU(0) . * . I-PDU( W - 1) . The algorithm executed by the sending LLC is presented in Fig. 10. Note that an ACK-REQ sent by the sending LLC contains two parameter: a sequence number of the last sent I-PDU (Pq - 1) and the value of the local ack-bit.

The receiving LLC manages 2 pointers, that define the receiving LLC window Wr. Wr contains the sequence numbers of I-PDUs the receiving LLC is ready to accept. Upon initialization, the receiving LLC sets Prt + 0, Pr2 c 1 Wrl - 1. From then on, each time it increases Prt by some value, it increases Pr2 by the

R. Cohen, Y. Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649 1643

0 O+l 1 t1 t3 15 t7 t9

t4

Fig. 9. The response bit.

<S.l> when the timer times,out <S.l.l> reset the timer <s.1.2> if Wsl U Wsz # 4 then <s.1.3> send ACK-REQ(Ps3 - l)( a&bit) <s. 1.4> Psz +- Ps3

<S.2> upon receiving ACK(z) or NACK(t)(list)(a) <s.2.1> if z E (Wsl U Wsz) then <s.2.2> while PSI # t + 1 do

PSI + PSI + 1 take a new message, and put it in Ws3 as I-PDU(Ps4) Ps4 + Ps4 + 1

<S.2.3> if this is a NACK and a = ack-bit then <S.2.4> resend all I-PDUs as indicated by list <S.2.5> reverse the ack-bit <S.2.6> send ACK-REQ(Psa - l)( ack-bit) <S.2.7> reset timer <S.2.8> Ps2 +- Ps3

<S.4> when Wsa is not empty <s.4.1> send I-PDU( Ps~) <S.4.2> PSBCPss$l

Fig. 10. Sender algorithm.

same value. Pigure 11 presents a formal description of the receiving LLC algorithm. Note that an ACK- REQ contains only one parameter: the sequence number of the last I-PDU received in sequence (Pri - 1) . A NACK, however, contains three fields as follows: ( 1) the acknowledgment bit, as copied from the ACK- REQ; (2) the sequence number of the last I-PDU received in sequence (Prl - 1) ; (3) a list of sequence

numbers of I-PDUs that should be resent (can be sent as a bit-map).

Selective-repeat requires the receiving LLC to maintain a local binary array, called accepred[]. The length of this array should be 1 WrJ. However, in order to simplify the presentation of the algorithm, we assume the array is as large as the sequence number space (i.e., contains N entries). Each time an I-PDU

1644 R. Cohen, E Ofek/Computer Networks and ISDN System 27 (1995) 1633-1649

<R.l> upon receiving I-PDU(i) <R.l.l> if i$ Wr then disregard this I-PDU

else <R.1.2> accepled[i] t 1 <R.l.3> while accepted[Prl] = 1 do <R.1.4> accepted[Prz] t 0 <R.l.5> deliver I-PDU(Prt) to the upper layer <R.1.6> Pq + Pr1+ 1 <R.1.7> PrstPrs+l

<R.2> upon receiving ACK-REQ(y)(a) <R.2.1> if y$ Wr then send ACK(Pri - 1) <R.2.2> else send NACK(Pri - l)( accepted[Pri . . . Y])(U)

Fig. 11. Receiver algorithm.

is accepted, the receiving LLC checks whether it can advance its window. This is done by the while loop in Fig. 11.

In the Appendix, the following theorem is proven:

Theorem 1. (a) All the I-PDUs submitted to the sending LLC by its upper layer are delivered by the receiving LLC to its user within a finite time, in the same order; with no duplication.

(b) An I-PDU which has been sent and not lost is never resent.

6. The periodicity of the ACK-REQs

This section examines the relation between the periodicity of the ACK-REQs and the width of the sending LLC window which guarantees maximum throughput of the protocol. In addition, it explains why the approach where the sending LLC may send an ACK- REQ only after having received a response (ACK or NACK) to the previous ACK-REQ, would require to almost double the sending LLC window.

Maximum throughput can be achieved if the sending LLC works with full capacity as long as I-PDUS are not lost; namely, it is not required to wait for ac- knowledgments. Therefore, in the following analysis it is assumed that the sending LLC always has I-PDUs waiting for sending and that I-PDUs are not lost.

We first address the approach taken by the protocol, where an ACK-REQ is sent every r seconds. This case is depicted in Fig. 12(a). The first ACK-REQ is received by the sending LLC no later than 7 + r seconds after the sending LLC starts sending I-PDUs, where 7 is defined as the maximum round trip delay. Therefore, in order to ensure that the sending LLC will not have to stop sending I-PDUs before the receipt of the first ACK, the width of its window must be > 7+r seconds 3 .

We next show that a window width of 7 + r is sufficient in order to ensure continuous operation of the sending LLC not only before the first ACK is received but also before any subsequent ACK is received. To this end, consider the following division of the time axis into slots. Slot 0 starts at time 0 and ends at 7+r; slot i, where i > 0, starts at 7 + i . r and ends at I+ (i+ 1) . r. Note that the first slot is the longest one. In order to show that at any time t the sending LLC still has some “credit”, namely it does not have to stop and wait for the next ACK, let t be in slot i. Since it has already been shown that during slot 0 the sending LLC has enough credit, we consider i > 0 only.

Every ACK gives the sending LLC a credit of r seconds. Since until t the sending LLC has received at least i ACKs, the total credit the sending LLC has

3 Though the width of the window is usually measured in terms of number of I-PDUs, it can also be expressed in time units.

R. Cohen, E Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649 1645

(b) Fig. 12. The sender window for maximum throughput. (a) Multiple outstanding ACK-REQs are allowed. (b) Multiple outstanding ACK-REQs are not allowed.

-

been achieving until t is >_ 7 + 7 (the window width, which is the initial credit) plus i. T. On the other hand, the total credit the sending LLC has been spending until t is < IT t (i + 1) . T. Therefore, the claim holds.

Figure 12(b) shows what would happen if an ACK- REQ was sent only after the previous one was ac- knowledged. ‘The sending LLC sends an ACK-REQ for no frame immediately after connection set-up, and then once every 7 seconds. An analysis similar to the previous one shows that in such a case the width of the sending LLC window should be 2 . ‘T seconds. If T is chosen such that T < 7, then 2. (7 + T) G 2.7, which means that in the second approach the sending LLC window must be doubled.

service. It was shown that a non-FIFO layer can provide for semi-FIFO service. Then, a new protocol for reliable transmission of data over an unreliable semi- FIFO layer has been proposed. This protocol does not require FIFO for data, but only for control information. On the other hand, it uses only one timer and it does not require an estimate of the round trip delay in order to perform well. Therefore, the contribution of the paper is eliminating the deficiencies associated with non-FIFO in networks that may offer semi-FIFO service.

Appendix A

In this appendix, the following theorem is proven 7. Conclusion

This paper has dealt with the relation between the routing protocol and the end to end protocol for reliable transmission of data. It has shown why FIFO routing facil:itates the implementation and increases the performance of the protocol for reliable transmission of data.

The paper has introduced a new notion: Semi-FIFO

Theorem 1. (a) All the I-PDUs submitted to the sending LLC by its upper layer are delivered by the receiving LLC to its user within a finite time, in the same order; with no duplication. (6) An I-PDU which has been sent and not lost is never resent.

Assumption 2. (a) Following connection establish- ment the sending LLC and receiving UC are ini-

1646 R. Cohen, E Ofek/Computer Networks and ISDN Systems 27 (1995) 1633- I649

tialized. This means that there exist times to(s) and to(r) such that (I) at time to(s) PSI = Ps2 = Ps3 = 0, Psq = W and the first W messages are placed in Wss as I-PDU(0) + . . I-PDV(W - 1); (2) at time to(r) Prl = 0 and Pr2 = W hold at the receiving LLC; (3) during the time interval [min(to(s>, to(r>>,max(tds), tdr>l> there are no I-PDUs traveling from the sending LLC to the receiving LLC and no NACK or ACK in the opposite direction.

(b) An I-PDLJ or S-PDU (ACK-REQ, ACK, NACK) sent by one LLC entity is correctly received by the other entity with probability p > 0.

(c) It will be convenient to assume during the proof of correctness that the sequence number space is unbounded (N + co).

Lemma 3. If PSI > 0, the receiving LLC has already received I-PDU(O), I-PDV(l),. . . I-PDU(Psl - 1) and delivered them to the upper layer.

Proof. The sending LLC sets PSI +- x+ 1 only when an ACK( x) or a NACK( x) (list) (a) is received. In every ACK( x) or NACK( x) (list) (a) sent by the receiving LLC at time t, x represents the value of Pri - 1 at t. Therefore, we should show that until time t, the receiving LLC has accepted I-PDU( 0) , I-PDU( 1) , . . .

I-PDU( Pr I - 1) , namely that for every 0 5 i 5 Pr-1 - 1, accepted[ i] = 1. Since at initialization Prl is reset to 0, and since the receiving LLC increases Pri by 1 (in <R. 1.2>-<R. 1.7>) only if accepted[ Prl ] = 1, the lemma holds. Cl

Lemma 4. Prl > PSI always holds.

Proof. If PSI = 0, the lemma clearly holds. When PSI > 0, Lemma 3 claims that the receiving LLC has already accepted I-PDU(0) , I-PDU( 1). . . . , I- PDU( PSI - 1). Therefore, acceptedli] = 1 holds for every 0 5 i 5 PSI - 1, and <R. 1.2>-<R.1.7> in the receiving LLC algorithm imply that Pri > PSI - 1. 0

Lemma 5. Psi always increases.

Proof. Suppose the lemma is not true; namely PSI = C holds forever. First, consider the case where the receiving LLC accepts I-PDU( C); thus, acceptedi C] =

I holds. Since PSI = C, from Lemma 3 follows that I-PDU(O), I-PDU( l), . . . , I-PDU(C - 1) have been accepted as well. Therefore, accepted[ i] = 1 holds for every 0 5 i 5 C, and <R.1.2>-CR. 1.7> in the receiving LLC algorithm imply that Pri >_ C + 1. Since the sending LLC sends ACK-REQs occasionally, As- sumption (b) implies that the receiving LLC receives an infinite number of correct ACK-REQs after I- PDU(O),I-PDU( 1), . . . , I-PDU( C - 1) are accepted. The receiving LLC replies to each of these ACK- REQs with an ACK(x) or a NACK(x)(fist) (a), where x = Pri - 1 1 C. Therefore, the sending LLC receives an infinite number of correct ACK(x) or NACK(x) (list) (a) with x > C after PSI = C holds. Upon receiving such a PDU Psi 2 x + 1 must hold. Since x > C, we get a contradiction.

Next, suppose the receiving LLC never accepts I- PDU(C). Thus, accepted[C] = 0 holds forever, im- plying that Pri < C + 1 holds forever as well. Since Ps i = C, we have Pri < PSI. But from Lemma 4 follows that Pri 2 PSI. Thus, Pri = Ps, = C must hold. Since the sending LLC occasionally sends an ACK- REQ( Pss)(a), and since Ps3 > PSI, the receiving LLC receives an infinite number of ACK-REQ( y) (a) where y = Ps3 > PSI = C. Since accepted[C] = 0, the receiving LLC replies to each ACK-REQ(y) (a) received after t with a NACK whose list field indicates that I-PDU(C) should be sent. Thus, the receiving LLC receives an infinite number of such NACKs.

Consider a pair of an accepted NACK and the ACK- REQ triggering this NACK. From the receiving LLC algorithm follows that both have the same acknowledgment bit a. The value of a is equal to the value of the sending LLC variable ack-bit when the ACK-REQ is sent. Now there are two possibilities as follows. If when the NACK is received ackbit = a holds, the sending LLC executes <X2.4>-<X2.8> and resends I-PDU( C). If, when the NACK is received ack-bit f a, the sending LLC has already executed <S.2.4>- <S.2.8> and resent I-PDU( C) after sending the ACK- =Q.

The conclusion is that the sending LLC sends an infinite number of I-PDU(C) after Prt = C. There- fore, the receiving LLC must receive this I-PDU( C) correctly, in contradiction to our assumption. 0

Definition 6. Whenever the sending LLC executes <S.2.4>-<S.2.8>, it is said to be in resend mode.

R. Cohen, E Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

RECEIVING LLC Fig. A.l. Proof of Lemma 7.

Lemma 7. Suppose the sending LLC sends at t an ACK-REQ, and that the receiving LLC replies by a NACK which is received by the sending LLC at t’. Then, this NACK causes the sending UC to enter resend mode only if it has not been in this mode during rt, t’l.

Proof. Assume the claim is not true. Consider thejrst ACK-REQ/NACK handshake contradicting the claim. Without loss of generality, let ackbit = 1 holds when the sending LLC sends this ACK-RFQ (at t). Thus, the acknowledgment bit a in the ACK-REQ as well as in the NACK .is 1.

The assumption that the claim does not hold for this ACK-REQ/NACK handshake means that: ( 1) ack-bit = 1 holds for the sending LLC at time t’; (2) during [t, t’] the sending LLC enters resend mode at least once. Let tl be the first time when the sending LLC enters resend mode during [t, t’] , as shown in Fig. A.l. This implies that at time tl the sending LLC receives a NACK with a = 1. Each time the sending LLC enters resend mode, it change the value of ack-bit. Therefore, at time t, ack-bit +- 0. Since ack-bit = 1 holds at t’, the sending LLC must enter resend mode at least one more time during [ tl , t’] , at time t2 say. This means that the sending LLC receives NACK(x)(Zist)(O) at t2 (where tl < t:! < t’), as a response to an ACK-REQ( y) (0) sent before, at to < t, and enters resend mode though it has been in resend mode during [to, t2] (at tl >. Thus, the claim of the lemma does not hold for this ACK-REQ/NACK too. Since this ACK-REQ/NACK handshake precedes the one considered above as the first for which the claim does not hold, we get a contradiction. q

Lemma 8. The sending LLC never resends an I-PDU unless any previously sent copy of this I-PDU has been lost.

(b) Fig. A.2. Proof of Lemma 8.

Proof. Suppose the claim does not hold. Let t’ be a time when the sending LLC resends I-PDU( i) , though an old copy of this I-PDU, sent at time t”, is correctly received. Note that Lemma 4 and the fact that the width of the receiving LLC window is equal to the width of the receiving LLC window imply that any correctly received I-PDU is also accepted by the receiving LLC. This is because any sent I-PDU is in the receiving LLC window. The sending LLC resends an I-PDU only in resend mode. Consider the NACK caused the sending LLC to enter resend mode at t’, and let t be the time when the ACK-REQ triggering this NACK is sent.

Consider now the following two possible relations between t and t”:

l t” < t (Fig. A.2( a) ). Since FIFO is retained for ACK-REQ, the receiving LLC receives the ACK-REQ sent by the sending LLC at t after accepting I-PDU( i) . Thus, the NACK triggered by this ACK-REQ does not include a request for retransmission of I-PDU( i) , in contradiction to our assumption.

R. Cohen, E O$ek/Computer Nehvorks and ISDN Systems 27 (1995) 1633-1649 1648

0

t” > t (Fig. A.2( b) ) . Since the NACK received at t causes the sending LLC to resend I-PDU( i), the value of the y field of the ACK-REQ was 2 i. This implies that the sending LLC sent before t at least one copy of I-PDU( i) and that at t Pr3 > i holds. Thus, at t”, when the sending LLC sends I-PDU( i), it is in resend mode. However, this contradicts Lemma 7 because the sending LLC enters at t’ to resend mode though he has already been in this mode at t” E [t, t’] .

Proof of Theorem 1. Part (a) of the theorem follows from Lemma 4 and Lemma 5; part (b) is proven in Lemma 8. 0

During the proof it was convenient to assume that the sequence number space is unbounded, namely N+- 0;). Under this assumption, each sequence number was used only once and we did not struggle with the question how the receiving LLC distinguish between two different I-PDUs that use the same sequence number.

Protocols for reliable transmission of data whose underlying layer does not retain FIFO indeed use a very large sequence number space in order to avoid sequence number re-use. For example, the sequence number space of the TCP is 232.

When the underlying layer retains FIFO, it is much easier to obtain a safe sequence number space. It is well known that N >_ W - 1 is sufficient for go- back-N protocols whose underlying layer retains FIFO and that N 2 2 . W is sufficient for selective-repeat protocols over FIFO routing layer [ 131.

It turns out that also with respect to the sequence number space, the new protocol is closer to protocols for FIFO networks rather than to protocols for non- FIFO networks. This is because for the new protocol N 2 2. W is as good as N -+ cc.

References

[ 1 J M. Cohn, A lightweight transfer protocol for the U.S. navy SAFENET local area network standard, Proc. 13th Conf on Local Computer Networks, Minneapolis, Minn., October 1988.

[2] D. Comer, bzternehvorking With TCP/IP, Prentice-Hall, Englewood cliffs, N.J. (1988).

[31

[41

I51

161

[71

181

[91

1101 1111

rt21

W. Doeringer, D. Dykeman, M. Kaiserswerth, B. Meister, H. Rudin, and R. Williamson, A survey of lightweight transport protocols for high-speed networks, IEEE Transactions on Communications 38( 11) (1990) 2025- 2039. B.T. Doshi and PK. Johri, Communication protocols for high speed packet networks, Computer Networks and ISDN Systems 24 (1992) 243-273. Draft new D-U-T Recommendation Q.SAAL.1: Service Specific Connection Oriented Protocol (SSCOP) Specification. S. Heatley and D. Stokesberry, Analysis of transport measurements over a local area networks, IEEE Communications Magazine (June 1989) 16-22. Institute of Electrical and Electronics Engineers Inc., ANSI/IEEE standards 802.2-1989 (IS0 8802-2): Logical link control, 1989. N. Maxemchuk, Routing in the manhattan street network, ZEEE Transactions on Communications 35 (5) ( 1987) 503- 512. Y. Ofek and M. Yung, Principles of high speed network control, Proc. 9th Annual ACM Symp. of Distributed Computings, August 1990, pp. 161-175, Protocol Engine, XTP protocol definition, revision 3.6, 1992. K. Sabnani, A. Netravali, and W. Roome, Design and implementation of a high speed transport protocol, IEEE Transactions on Communications 38 ( 11) (1990) 2010- 2024. M. Schroeder, A. Birmll, M. Burrows, H. Murray, R. Needham, T. Rodeheffer, E. Satterthwaite, and C. Thacker, Autonet: A high-speed, self-configuring local area network using point-to-point links, IEEE Journal on Selected Areas in Communications 9 (8) (1991) 1318-1335.

[ 131 A. Tanenbaum, Computer Networks, Prentice-Hall, Englewood Cliffs, N.J. ( 1989).

[ 141 A.C. Weaver, Making transport protocols fast, Proc. 16th Conf: on Local Computer Networks, Minneapolis, Minn., October 1991, pp. 295-300.

[ 151 L. Zhang, Why SIGCOMM, 1986.

TCP timers don’t work well, Proc.

Reuven Cohen was born in Israel in 1961. He received the B.Sc., M.&c. and Ph.D. degrees in Computer Science from the Technion, Israel Institute of Tech- nology in 1986, 1988 and 1991 respectively. During 199 I, he was a lecturer in the Faculty of Computer Science at the Technion. From 1991 to 1993, he was with the IBM T.J. Watson Research Cen- ter, Yorktown Heights, N.Y. His main research interests are access control protocols for ring networks, connection ar-

chitecture of ATM networks, protocols for reliable transmission of data, signalling protocols and video-on-demand networks. Dr. Cohen is currently with the Department of Computer Science at the Technion, Israel Institute of Technology.

R. Cohen, Z Ofek/Computer Networks and ISDN Systems 27 (1995) 1633-1649

Yoram Ofek received his BSc. degree in Electrical Engineering from the Tech- nion, Israel Institute of Technology in 1979, and his M.Sc. and Ph.D. degrees in Electrical Engineering from the Uni- versity of Illinois-Urbana in 1985 and 1987, respectively. From 1979 to 1982 he was affiliated with RAFAEL, as a reseach engineer. During 1983-1986 he was with Gould Electron- ics, Urbana, Ill. Since 1987 he has been a research staff member at the IBM T.J. , Yorktown Heights, N.Y. His main re-

search interests are access control, routing, flow control and fai- ness in local and wide area networks, high speed optical networks, distributed algorithms and parallel systems, clock synchronization, self-stabilization, and fault tolerance. Dr. Ofek was the program Co-chairperson of the 6th IEEE Work- shop on Local and Metropolitan Area Networks. He has been on the program committee of INFOCOM, and a guest editor for IEEE Journal of Selected Areas in Communications. In IBM Dr. Ofek has initiated the research activities on ring LANs with spa- tial bandwidth reuse and switch-based LANs, in 1988 and 1989, respectively, and has been leading the research activities on the MetaRing and MetaNet architectures.

1649

Documents

Reliable transmission of data over a semi-FIFO routing layer