TCP flow control technique for an interworking interface: hardware implementation

Ž .Computer Standards & Interfaces 23 2001 383–397www.elsevier.comrlocatercsi

TCP flow control technique for an interworkinginterface: hardware implementation

Ridha Ouni a,1, Adel Soudani a,1, Salem Nasri a,1, Kholdoun Torki b,),Mohamed Abid a,1, Rached Tourki a,1

a ´ ´ ( )Laboratoire d’Electronique et de Micro-Electronique EmE , Faculte des Sciences de Monastir, Tunisia´b ( )Techniques de l’Informatique et de la Microelectronique pour l’Architecture d’ordinateurs TIMA ,´

( )Institut National Polytechnique de Grenoble INPG , Grenoble, France

Received 10 April 2001; received in revised form 8 July 2001; accepted 31 July 2001

Abstract

Current TCP flow control depends on packet losses to find the workload that a network can support. A variety ofsituations, including lossy wireless networks, asymmetric networks and web traffic workload, violates many of theassumptions made by TCP, causing degraded end-to-end performances. To improve the performance of TCP over

Ž .heterogeneous networks Ethernet and ATM interconnection , we propose a new technique, which we call Vegas–Snoopq ,based on Vegas and Snoop protocols. Two modified service elements take part on the Vegas–Snoopq technique. First,Vegas service element manages the connection parameters to achieve better throughput. Second, Snoop service elementisolates the Ethernet senders from the characteristics of the ATM link. The objective in this paper is to win from advantagesof Vegas and Snoop protocols, as well as to search an interconnection interface for networks interoperability. Actually, the

Ž Ž . Ž ..development of two new integrated circuits the BCM5680 switch and the BCM5401 PHY orientate researchers toimplement, at higher layer of the OSI model, flow control mechanisms to ensure reliability. Vegas–Snoopq is animplementation of TCP, which gives in this way a solution for traffic management and congestion control improving goodthroughput with more reliability. q 2001 Elsevier Science B.V. All rights reserved.

Keywords: Congestion control; TCP; Interconnection interface; End-to-end protocols; Hardware implementation

1. Introduction

The robustness of TCP in a wide variety ofnetworking environments is the primary reason forits large-scale deployment. In addition, the growth of

) Corresponding author. Tel.: q33-76-57-45-00; fax: q33-76-47-38-14.

Ž .E-mail addresses: [email protected] R. Ouni ,Ž [email protected] K. Torki .

1 Tel.: q216-3-500-279; fax: q216-3-500-278.

the Internet and the World Wide Web has increasedthe diversity of situations in which TCP connectionsare used. There are two aspects to this diversity:heterogeneous networks and new traffic workload.However, emerging networking technologies posenew challenges to TCP in terms of performance,requiring analysis and solutions. This paper focuseson two challenges. The first is the end-to-end TCPperformance that arises due to network asymmetry.The second is the split scheme, which uses an inter-

Ž .mediate host base station to divide a TCP connec-tion into two separate TCP connections.

0920-5489r01r$ - see front matter q 2001 Elsevier Science B.V. All rights reserved.Ž .PII: S0920-5489 01 00090-3

( )R. Ouni et al.rComputer Standards & Interfaces 23 2001 383–397384

This study is not limited to networking protocolsand improving performances. We also study thepossibility to perform a new technique for flow andcongestion control on a hardware implementation. Adesign methodology is, therefore, adopted followingan HDL description, verification at several abstrac-tion levels, synthesis and place and route. The appli-cation consists of interconnecting two high-speednetworks using lower layer Ethernet and ATM speci-fications. The system allowing this interconnection,called gateway, should provide three main tasks.First, the conversion of exchanged information fromEthernet frame format to ATM cell representationand vice versa. The second and third tasks concernthe control of traffic at the ATM and the Ethernet

Ž .network sides, respectively Fig. 2 . A new TCP-based technique is proposed, for flow and congestioncontrol at the Ethernet network side. It presentsadvantages of this technique behind several TCPimplementations and outlines results given by themost developed hardware design tools.

Recently, several schemes have been proposed toimprove TCP performances. Two different ap-proaches are defined in lossy systems. The firstapproach hides any non-congestion-related lossesfrom the TCP sender. Protocols that adopt this ap-proach, such as the Snoop protocol, attempt to makethe lossy link appear as a higher-quality link with areduced effective bandwidth. As a result, most of thelosses seen by the TCP sender are caused by conges-tion. The second class of techniques attempts tomake the sender aware of the existence of remotehops and reflects that packet losses are not due onlyto congestion. The sender can then avoid invokingcongestion algorithms when non-congestion-relatedlosses occur. Then, it is possible for an aware trans-port protocol to coexist with link-layer schemes toachieve good performance. In this context, TCPVegas is a new implementation of TCP that achievesbetter throughput, with lower losses than TCP Reno.In summary, the objective here is to search a newtechnique that implements simultaneously the twoclasses without requiring any changes in both senderand receiver end-systems. This technique, called Ve-gas–Snoopq , integrates, in the ATM–Ethernetgateway, service elements modified from Vegas andSnoop protocols in order to be able to manage andcontrol traffic efficiently.

The rest of this paper is organized as follows.Section 2 describes an overview on TCP protocoland its features. Section 3 presents three implementa-tion schemes for TCP flow control. Section 4 detailsan algorithm implemented to manage traffic at an

Ž .internetwork unit. This algorithm Vegas–Snoopqis a modified mechanism from the Vegas and Snoopprotocols. Section 5 outlines the design methodologyand results as an application of Vegas–Snoopqmechanism at an ATM–Ethernet Gateway. Finally,Section 6 draws conclusions and outlines the futureworks.

2. TCP overview

TCP is a connection-oriented, reliable, ordered,byte-stream protocol with explicit flow control. Asending host divides the data stream into individualsegments, each of which is no longer than the Sender

Ž .Maximum Segment Size SMSS determined duringestablished connection. Each segment is labeled withexplicit sequence numbers to guarantee ordering and

w xreliability 20 . TCP assumes congestion in the net-work to be the primary cause for packet losses and

w xunusual delay 4 . TCP performs well over suchnetworks by adapting to end-to-end delays and con-gestion losses. The TCP sender uses received cumu-lative acknowledgements to determine which packetshave reached the receiver, and ensures retransmittinglost packet. If outstanding data is not acknowledgedfor a period of time, the sender will timeout andretransmit the unacknowledged segments. For thispurpose, it maintains a running average of the esti-

Ž .mated Round-Trip-Time RTT and the mean lineardeviation from it. The sender identifies the loss ofpacket by the arrival of several duplicate acknowl-edgements or the absence of an acknowledgment forthe packet within a timeout interval.

TCP is also called window-based protocol. Thesize of the socket buffers that should be used in TCPexperiments gives accordingly congestion window

Ž .size. We note that the standard TCP header Fig. 1Žlimits the advertised window size available receiver

.socket buffer size to 64 KB, which is not adequatew xin many situations 18 . The maximum window size

is generally the minimum of the send socket buffer

( )R. Ouni et al.rComputer Standards & Interfaces 23 2001 383–397 385

Fig. 1. Format of TCP packet.

Ž .at the TCP sender and the receive socket bufferŽ .advertised window on the receiver . The TCPsender’s congestion window may further limit theamount of data the sender can inject in the network,depending on the level of congestion in the network

w xpath 2 .In TCP, window management is not directly re-

lated to ACKs existing in many data link protocols.The available memory space in the receiver can alsomanage the window size. In fact, when the sourcesends a segment filling more memory space in thereceiver, it should send back an acknowledgement inwhich it indicates the new window size. Obviously,the new window value is less than the last. More-over, whether the source remains sending segments,the available receiver buffer decreases as well as thewindow size, which can reach a small value whenapplication in receiver side does not retires data. Inthis situation, few primitives manage transmissionpolicies and result to supervise traffic and congestioncontrol problems. TCP uses several algorithms forcongestion control, most notably slow start and con-

w xgestion avoidance 11,21 . These algorithms are win-dow-based flow control mechanisms. Each of themcontrols the sending rate by manipulating a conges-tion window that limits the number of outstandingunacknowledged bytes that are allowed at any time.Recently, several schemes have been proposed toalleviate the effects of non-congestion-related losses,as well as congestion avoidance on TCP perfor-

w xmance over networks that have high-loss links 3,19 .These schemes use mechanisms, such as local re-transmission, split-TCP connections and forward er-ror correction, to improve end-to-end throughput.

w xSection 3 details these schemes 8 .

3. Implementation schemes

This section describes protocols mainly the keyideas in each scheme and the main difference be-tween them. It is interesting here to show whichschemes can use the gateway when TCP is theprotocol adopted for transmission control over anetwork.

3.1. End-to-end schemes

The current standard for TCP implementation isw xTCP Reno 21 , called end-to-end protocol. It is used

as a standard basis for performance comparison.Thus, it appears that successive versions of TCP andresearchers trends objectives attempt usually to de-velop new reliable TCP protocol versions. The end-to-end new Reno protocol improves TCP Reno per-formance after multiple packet losses. This isachieved by maintaining the fast recovery mode if

Ž .the first acknowledgement ACK received after afast retransmission is less than the sequence of thelast transmitted byte. This scheme allows recoveringlosses at one segment per RTT and not waiting atimeout.

Besides, the end-to-end Smart and the end-to-endIETF-SACK protocols add Smart and IETF-Selec-

Ž .tive Acknowledgements SACK options, respec-tively. The Smart-based scheme allows reordering

w xpackets 14 . IETF-selective acknowledgement startscongestion control procedures after receiving SACK.These schemes assume that losses are caused bycongestion. They consequently activate congestionprocedures in order to shrink congestion windowsize. To detect losses caused by transmission errors,another protocol introduces an Explicit Loss Notifi-

Ž .cation ELN primitive to TCP acknowledgement.

3.2. Link layer schemes

Existing link layer protocols choose from severaltechniques, such as stop-and-wait, forward error cor-rection, etc., to ensure reliability. In our applicationŽ .Fig. 2 , link layer algorithm may use cumulativeacknowledgement to detect losses of packets, whichwill be retransmitted locally from the gateway to thedestination network. To limit the timer processingoverhead when timeout-based retransmissions are


Fig. 2. Gateway-managing traffic between two high-speed net-works.

used, we need to maintain a smoothed RTT ofminimum 200 ms. The link layer protocol is equiva-lent to Snoop agent, implemented in a base station

w xby Ref. 4 . This fact preserves the ability of retrans-mit packets locally and independently within a fastertime scale than TCP. Consequently, this implementa-tion proved to be applicable to general link layerprotocols.

The link layer smart version uses selective re-transmissions to improve performance. Thereafterappears the TCP awareness option outlining twoother versions: the link layer TCP Aware and theLink Layer Smart TCP Aware schemes. The first

w xscheme is identical to the Snoop protocol 4 , whichwill be modified and implemented in the gatewayŽ .more detailed in Section 4 .

3.3. Split connection schemes

w xIn Ref. 4 , split scheme uses an intermediate hostŽ .base station to divide a TCP connection into twoseparate TCP connections. In the same way, Fig. 2introduces a gateway between ATM and Ethernetnetworks, which should support two types of func-

w xtionalities. Adaptation of frame format 16 and traf-fic control such as the one implemented in the basestation. These functionalities require loading databefore starting conversion and control tasks. Split-smart is a variant of the split approach that usesselective acknowledgement scheme to perform selec-tive retransmission. The main advantage of this ap-proach is that it isolates the TCP source from lossesoccurring over the destination link. This advantage

Ž .will be seen in our implementation Section 4.2 .

4. Vegas–SnoopH : extended Vegas and Snoopprotocols

TCP hosts can implement various TCP flow andcongestion control mechanisms for effective networkbandwidth utilization. Actual TCP versions for con-gestion control and avoidance introduce mechanismsthat increase performances in terms of losses andnumber of retransmission. In this section, we presenta window-based TCP traffic control model devel-oped to be integrated in a gateway between twohigh-speed networks: Ethernet and ATM networks.

In the gateway–Ethernet network interface, dataflow should be managed by a protocol taking inaccount the specificity of each interconnected systemand ensuring reliability. Transmission Control Proto-col is a connection-oriented protocol, specially de-signed for an end-to-end data processing at highlevel of reliability. Moreover, emerging networkingtechnologies pose new challenges to TCP in term ofperformance, requiring analysis and solution for spe-cific application by developing new TCP-based ver-sions. Vegas and Snoop protocols are two TCP-basedversions that perform better throughput in a varietyof situations, including lossy wireless networks and

w xasymmetric networks. Vegas 5 is a new version ofTCP that achieves more than 40% throughput, withlow losses as compared to TCP Reno. Snoop proto-col isolates wired senders from the lossy character-istics of a wireless link. To improve TCP perfor-mance over networks exhibiting asymmetry, we havedesigned and evaluated a Vegas and Snoop combina-tion that implements an integrated congestion controland loss recovery approach. The next paragraphsattempt to go beyond earlier works, to provide newinsights into congestion control and to propose modi-fications to the TCP implementation that exploitthese insights.

4.1. SerÕice element from Vegas protocol

The tangible result of this effort is a new imple-mentation of TCP called AVegas–SnoopqB that werefer to as Vegas and Snoop implementations. Notethat Vegas–Snoopq does not involve any changesto TCP specification. It could then interoperate withany other TCP implementation. The benefits of thisimplementation are that contributions are confined to


both sending and receiving sides. This is neededbecause the gateway should control traffic betweentwo networks in the two directions.

Early in this effort, it became clear the need of agood facility to analyze and manage the behavior ofTCP. Therefore, adding signals allows displayingvariations of each TCP parameter. Signals should beimplemented according to bit vectors with an opti-mal size sweeping the necessary gap of variation.Simulation tool displays the tracing information giv-ing explicit behavior and then verification possibili-ties could converge into correct implementation ofthe algorithm.

This section introduces and describes techniquesthat Vegas–Snoopq employs to avail from advan-tages of TCP Vegas. These advantages attempt toincrease throughput and decrease losses, using twotechniques. The first technique requires retransmis-sion of dropped segments within timely delay. Thesecond technique avoids problems succeeding con-gestion, and then provides the ability to adjust ac-cordingly the transmission rate.

4.1.1. Retransmission mechanismw xTechniques proposed elsewhere 4,5 give ideas

that the RTT and then the retransmission decisionŽare based upon a coarse-grained timer around 500

.ms . In the hardware implementation, an integratedspecific module assumes interoperability between thegateway and a software implementation running over

Ž .microprocessor Fig. 2 . This soft task achieves anoncritical path and gives the gateway the necessarytemporal information through interfacing ports. Re-quests can be provided to microprocessor in order tobackward loaded information, such as timer state andlast ACK sequence.

TCP Reno retransmits segments when a coarse-grained timeout occurs and if the third duplicateACKs is received. It sends a duplicate ACK when-ever it receives new data that it cannot acknowledgebecause it has not yet received all the previous data.When the sender receives the third duplicate ACK, itretransmits the dropped packet. Vegas–Snoopsqadopts these mechanisms and extends retransmissionservices that can provide over hardware implementa-tion more efficiently. Vegas–Snoopq reads andloads the system clock each time a segment is sent orACK is received. When an ACK arrives, Vegas–

Snoopq uses the read time and the last timestampŽ .to calculate the new Round-Trip-Time RTT value.

Then, Vegas–Snoopq uses as Vegas the accuratew xRTT to decide retransmission for two cases 5 :

v Vegas–Snoopq does not have to wait for thethird duplicate ACK, when a duplicate ACK isreceived simultaneously if the difference be-tween the current time and the last timestamp isgreater than the timeout.

v Segment should be retransmitted also even if anonduplicate ACK is received after a retrans-mission, but the sending time interval is greaterthan the timeout.

These two points introduce an interesting fact thatACKs trigger the flow control mechanisms that an-ticipate congestion and adjust transmission primi-tives accordingly. Then, they decrease the processingtime interval, reduce difficulties in the global controlmodel, and then change parameters only for specificevents. Consequently, congestion window shouldonly be reduced due to losses that happened at thecurrent sending rate, and not due to losses thatoccurred at an earlier, higher rate. In other words,losses happening before the last window decrease donot imply congestion in the network for the currentcongestion window size. Therefore, they do not im-ply to decrease it again.

4.1.2. Congestion aÕoidance techniqueSeveral researchers have not only to identify solu-

tion for congestion problems but also to proposemechanisms for congestion avoidance, i.e. TCPReno’s congestion detection and control mechanismuses the loss of segments to indicate congestion inthe network, so it can prevent hosts. Previouslyproposed approaches increase queue size in the inter-mediate nodes, leading to increase the RTT for

w xsuccessive segments. Ref. 23 is based on the in-crease of RTT. It succeeds, every two round tripdelay, to achieve specific parameter changes accord-ing to the difference between the current RTT and

w xthe average of RTTs seen so far. Jain’s 12 approachis based on an analytic derivation of the window sizefor a deterministic network. The window size is

Ž .adjusted increased or decreased every two RTTŽaccording to the following product sign negative or

. Ž .Ž .positive : Win yWin RTT yRTT .curr old curr old


Vegas–Snoopq starts slowly such as slow-startimplementation that will be detailed in Section 4.3.Every RTT, Vegas–Snoopq increases the windowsize by one segment, calculates the achievedthroughput and react to attempt flatten sending rate.This reaction results from comparison between mea-sured throughput rate and expected throughput rate.Vegas, as well as Vegas–Snoopq , suggest that thenumber of byte in transit is directly proportional tothe expected throughput, taking origin from windowsize variation. Fig. 3 presents the Vegas serviceelement extracted and then modified to be able tocontrol traffic in the Ethernet side of the gateway.The service element behavior is founded upon fourschemes.

Ž .1 Each connection establishment defines a baseRTT as initial value set to the minimum of allmeasured values of RTT. Each connection changesthis value accordingly in function of the traffic inten-sity as outlined in scheme 2. In this case, andespecially when we are not overflowing the connec-

Ž .tion, the expected throughput is given by Eq. I ,

Fig. 3. Algorithm for congestion control: extended Vegas serviceŽ .element cwnd: congestion window .

where the window size is equal to the counted bytesin transit.

Expected thrputswindow sizerbase RTT IŽ .Ž .2 Each round trip time, Vegas–Snoop q

achieves many steps to calculate the Actual sendingrate that will be used to manage congestion windowvariation. In fact, Vegas–Snoopq :

v loads the sending time for a distinguished seg-ment;

v Ž .counts and loads the number of bytes Nbytetransmitted between sending a segment and re-ceiving its acknowledgement; then calculatesthe RTT for the distinguished segment;

v finally, deduces the actual sending rate by divid-ing the number of bytes transmitted by the RTT.

ActualsNbyterRTT IIŽ .Ž .3 Vegas–Snoopq defines two thresholds a

and b as a-b. These parameters serve to controlthe size of the congestion window. The b thresholdtriggers the congestion window decrease, whereasthe a threshold triggers the increase. In practice, thethresholds a and b , affected over bit vector signals,are expressed in terms of buffers.

Ž .4 Vegas–Snoopq compares, therefore, Actualto Expected, and adjusts the window size according

Ž .to the difference Diff between them. Let DiffsExpectedyActual. Diff is positive by definition,since Actual)Expected implies that we need tochange base RTT to the latest RTT. When Diff-a ,Vegas–Snoopq increases the congestion windowlinearly during the next RTT. When Diff)b , Ve-gas–Snoopq decreases the congestion window lin-early during the next RTT. Vegas–Snoopq leavesthe congestion window size unchanged when a-

w xDiff-b 5 .Vegas–Snoopq congestion avoidance mecha-

nisms, detailed in Fig. 3, adopt throughput to thechanging conditions on the network. Intuitively, thesending rate should be reduced when actual through-put is greater than the expected throughput. And thenthe connection does not use the available bandwidth,when the actual throughput gets too close to theexpected throughput.


4.2. SerÕice element from Snoop protocol

Networks with higher bit-error, such as those withwireless links, violate many of the assumptions madeby TCP, causing degraded end-to-end performance.For this reason, an important proposal requires toassociate with Vegas service element another com-plementary service. This section describes the designand the implementation of a service element modi-

w xfied as proposed in the Snoop protocol 4 . Thisservice element modifies network-layer implementa-tion in the gateway and preserves end-to-end TCPsemantics. The main idea of the Vegas–Snoopqdesign is to cache packets at the gateway and per-form local retransmission across Ethernet and ATMnetwork links in both directions.

In the presence of high error rates and intermittentconnectivity characteristics of different links, TCPdrops its transmission window size before retransmit-ting packets, initiates congestion control or avoid-

Ž w x.ance mechanisms e.g., slow start 11 and resets itsŽ w x.retransmission timer Karn’s algorithm 13 . These

measures reduce unnecessarily link’s bandwidth thatcause a significant degradation in performance sum-marized by low throughput and high interactive de-lays. In introducing the Snoop service element, weattempt to alleviate this degradation based on severallast experiments using this protocol. Then, it allowsimproving the end-to-end performance on the gate-way as sending side as well as receiving side.

4.2.1. Data transfer from Ethernet networkWe describe the service element used to manage

the data transfer from the Ethernet network. Addinga module, called the Snoop, as presented in Vegasservice element section, modifies the gateway rout-ing code. This module monitors every packet thatpasses through the connection in either direction.Vegas–Snoopq maintains a cache of TCP packetssent from the Ethernet and have not yet been ac-knowledged by ATM network. When a new packetarrives from the Ethernet network, Vegas–Snoopqadds it in its cache and passes the packet on to therouting code. It also keeps track of all the acknowl-edgements sent from the ATM network. In summary,Vegas–Snoopq has two linked procedures, VS data–and VS ack, which allow processing data packets–and acknowledgements coming from and intended

for the Ethernet network respectively. These proce-dures are described below.

VS data processes packets from the Ethernet net-–work. TCP implements a sliding window scheme totransmit packets based on its congestion windowŽ .estimated at the sender and the flow control win-

Ž .dow advertised by the receiver . TCP is a bytestream protocol and each byte of data has an associ-ated sequence number. The Vegas service elementmanages congestion window by local computationsand identifies each TCP packet uniquely by thesequence number of its first byte of data and its size.At the gateway, the Snoop service element keepstrack of the last sequence number seen for the con-nection. According to the sequence number of eachpacket that arrives at the gateway from the Ethernetnetwork, VS data processes them differently as out-–lined in following paragraphs.

Ž .1 A new packet in the normal TCP sequence:this is a common case, when a new packet in thenormal increasing sequence arrives. This packet is,therefore, added to the Vegas–Snoopq cache andforwarded, after segmentation into cells, to the ATMnetwork. We also place a timestamp on one packetper transmitted window in order to compute the RTTof ATM link.

Ž .2 An out-of-sequence packet that has beencached earlier: this case could occur when a droppedpacket causes timeout at the sender. Depending onwhether the packet sequence number is greater orless than the last acknowledged packet, the gatewayprocesses differently these packets. If the sequencenumber is greater than the last acknowledgement, thepacket is forwarded to the ATM network. Because itis very probable that this packet does not reach thereceiver earlier. However, when the sequence num-ber is less than the last acknowledgements, the ATMnetwork has already received this packet and it couldbe discarded. However, it is not usually the bestaction because the original ACK, sent to the Ethernetnetwork, could be congested. An important actionachieved by the gateway is to be transparent betweeninterconnected networks, which enables networksender to quickly get the current state of connections.Each TCP acknowledgement seen at the gateway isgenerated and then sent to the Ethernet.

Ž .3 An out-of-sequence packet that has not beencached earlier: two causes could result in this case.


First, if the packet is congested in the Ethernet side,or it is delivered out of order from the senderŽ .Ethernet network . VS data forwards this packet to–the ATM network, and marks it as a retransmittedpacket. Besides, VS ack use this information to–process acknowledgements from the ATM network.The flowchart summarizing VS data is shown in–Fig. 4.

VS ack processes acknowledgements sent back–by the ATM network and triggers actions dependingon the type and number of acknowledgements it

w xcould receive. Three types of ACK are defined 4 .For each one, VS ack performs a correspondent–operation.

Ž .1 A new ACK: this is the common case thatsignifies an increase of packet sequence received atthe ATM network. VS ack cleans the memory cache–for all packets that are acknowledged. It starts RTTcomputing mechanism for receiver link once bytransmission window, and only when no retransmis-sions occur in this window. VS ack forwards this–acknowledgement to the Ethernet network.

Ž .2 A spurious ACK: this is a situation that rarelyseen by the Vegas–Snoopq module and, therefore,it is discarded.

Ž .3 A duplicate ACK: this situation happens whenthe same ACK as the last received one arrives at thegateway. This situation means that the ATM networkhas not yet received the next packet in sequence

Ž .from the duplicate ACK DUPACK . However, sub-sequent packets in the sequence have been received.The ATM network generates a DUPACK for eachpacket received out of sequence. VS ack then deter-–mines the lost packet as well as the following packetit will start with after retransmission. The followingitems outline specific action, depending on the re-ceived DUPACK.

v If the lost packet is not in the cache, it needs tobe resent from the Ethernet network.

v When Vegas–Snoopq processes the first DU-PACK, it expects to get the same ACK for otherkinds.

Fig. 4. Flowchart for data packet processing: VS data.–


v In order to make the number of DUPACK assmall as possible, Vegas–Snoopq retransmitsthe lost packet at high priority, i.e. as soon asthe loss is detected. Fig. 5 presents a flowchartfor flow control based on the Snoop serviceelement.

Vegas–Snoopq also performs retransmissiondriven by timeout. Timeout is controlled by twotypes of timer interrupts: the round trip timer and thepersist timer. The round trip timer is computed by

Ž .Eq. III , where srtt is the smoothed round-trip timew xand a is set to 0.25 4 . Retransmission is triggered

for a packet, when it passes twice this time withoutreceiving its acknowledgement. The persist timertriggers retransmission if there are unacknowledgedpackets in the cache, and if there has been no activityfrom either networks for 200 ms.

)

)srtts 1ya old srttqa curr rtt IIIŽ . Ž .– –

4.2.2. Data transfer from ATM networkBetween Ethernet and ATM networks, a modified

TCP protocol implementation at the gateway cannotsubstantially improve end-to-end performance of re-liable bulk data transfer from the ATM network toother hosts on the Ethernet network. For example,simply caching reassembled packets at the gateway

and retransmitting them as necessary will not be veryuseful since the packet losses are likely to be fromthe ATM network to the gateway. The idea here is todevelop an algorithm for flow control at the gatewayand in the ATM network side. A rate-based algo-rithm is developed and integrated in the gatewayallowing to control and to manage cell traffic. This

Ž .algorithm is based on the ABR Available Bit Rateservice.

4.3. Modified slow-start

Slow start procedure is initiated both at connec-tion start up and upon restart after an idle period.This requires several round trips to probe the net-

w xwork for bandwidth and ramp up its window 17 .While there are no losses, slow start doubles thecongestion window size every RTT, which expectsdoubling the attempted throughput. We could, there-fore, pass over permitted available bandwidth. Thisconfirms that the slow start mechanism is expensivein terms of losses. Besides, during short length trans-fer, probing leads to poor utilization of the availablenetwork bandwidth, and consequently, increased la-tency. The challenge, therefore, is to reduce latencyfor short transfers, but at the same time, to ensurereliability improved by smart congestion avoidance.To meet the last challenge, we introduce, in addition

Fig. 5. Flowcharts describing acknowledgement-processing algorithm.


Fig. 6. The congestion window increases exponentially and lin-w xearly within the transmission number 19 .

Ž .to transmission at the receiver and congestion win-dows, a third parameter called congestion avoidancethreshold. Vegas–Snoopq uses this parameter tolimit window increase by changing the window man-agement mode.

4.4. Implementation algorithm

Congestion control algorithm Vegas–Snoopqmakes the object of an efficient combination of theslow-start algorithm and the linear variation algo-rithm adopted by Vegas. It introduces, in addition to

Ž .transmission at the receiver and congestion win-dows, a third parameter called g threshold to super-vise congestion avoidance. Moreover, integrating aconcurrent Snoop-based algorithm, for state se-quence control, introduces more suppleness to theconnection management. The reliability is attempted

during short length data transfer as well as for goodavailable bandwidth utilization. Fig. 6 shows a curvemodel for congestion window variation function intransmission number.

As a default mode, slow-start is used to start eachconnection. Congestion window increases exponen-tially until reaching g avoidance threshold. At thislevel, successful transmission linearly increases the

Žcongestion window one sent segment for all acquit-.ted segments . Simultaneously, when every segment

Ž .data packet or acknowledgement arrives at thegateway, VS data or VS ack processes it respec-– –tively. In other words, modified slow-start and theadopted Vegas service element present the part ofVegas–Snoopq that manages the evolution ofworking parameters. However, the implementedSnoop service element ensures state machine progressaccordingly to events happening at the gateway inputports. Fig. 7 summarizes the interworking betweencombined service elements integrated to implementVegas–Snoopq algorithm at the Ethernet–ATMgateway. Section 5 rests on implementation method-ology and obtained results.

5. Application: flow control in an ATM–Ethernetgateway

Gateway design automation introduced Verilog in1983, and in 1987 VHDL became the first public-

w xdomain digit-hardware-modeling language 1 . To-gether, more by coincidence than by planning, the

Fig. 7. Vegas–Snoopq presented within concurrent FSMs.


two HDLs enabled the widespread use of synthesisw xand energized the ASIC industry 15 . Process engi-

neers and device physicists have reduced featuresizes to 0.15 mm and smaller and die sizes to thepoint at which each die can contain tens of millionsof usable transistors. System level description de-mands describing requirements and functions inde-pendently of implementation, making trade-offs be-tween hardware and software, and being able to talkabout interfaces and protocols without describing theactual hardware. Then to reach applications withmore performance, systems will still contain hard-ware, and the hardware description will be at theRTL.

5.1. Design methodology

Proposed methodology includes design reuse withw xvirtual on-chip components 10 , new tools starting atw xa higher level of abstraction 9,22 , the use of static

w xtiming analysis and formal verification 6 . The liter-ature describes the theory of these new methods andtheir potential advantages over established designmethodology. High-level synthesis tools permit de-signers to describe designs at different abstractionlevels. They also enable to analyze the total designspace to find the optimum implementation for thedesign by automatically searching for the best

Ž .scheduling of Finite-State Machines FSMs and thew xallocation of design units 7 . This section presents

practical design experience with the new methodol-ogy. We are interested in the hardware part and wechose to start the project with RTL VHDL.

5.1.1. Hardware descriptionThis project allows interconnection of two net-

works, Ethernet and ATM. In the main part consid-ered in this paper, Vegas–Snoopq is proposed as anown TCP-based traffic control algorithm. Consider-ing the project’s size and its dependence on standard-ized interfaces, network sides and microprocessorside, late design changes seemed likely.

Practically all units are designed as interactingFSMs, with recurring parts written partly as func-tions or procedures. The synthesis tool allows auto-matic scheduling, repartitioning of FSMs, and the

w xcorresponding allocation of resources 9,22 . WeŽgenerally required the existence of a reset state or a

.state with a corresponding behavior so that this statecould also be used for recovery from unassignedstate encoding patterns. Most units are synchronous,then they are modeled by a process that is triggeredat the rising edge of clock and for specific events atthe input ports. Finally, describing at the RTL ab-straction level is more difficult than at the behaviorallevel. However, the synthesis compilers achieve goodresults with VLSI designs at the RTL.

Our design model is based on concurrent andsequential FSMs. In this way, the Vegas serviceelement sequentially manages the switching betweenexponential and linear modes. VS data and VS ack– –supervise, respectively, the received segments andacknowledgements over another concurrent FSM.Besides, this last could trigger a timer that shouldwork independently to the other processes. FSMs aretranslated from flowchart representation to VHDLdescription using sequential and concurrent instruc-tions as well as temporal primitives provided at the

w xRTL level 1 . Dual and single port RAMs allow toload temporary information or data. However, itrequires respecting their interface and their timingspecifications. Especially, the cycle time, the read,the write and the address setup times and the read,the write and the address hold times are taken asimportant specifications that must be respected dur-ing the description of each FSM.

5.1.2. VerificationVerification in the RTL and gate levels justifies

the system in an advanced step. Gate level simula-Žtions are performed with the VITAL VHDL Initia-

.tive Toward ASIC Libraries technology models. A0.35-mm CMOS technology is employed as targetgate library. In this level, many encountered simula-tion problems are difficult to solve, caused by arith-metic operation units that need more critical pathoptimization to reach faster responses.

To realize RTL, as well as gate-level, simulationsof the complete chip, a verification system, writtenin behavioral VHDL, provides all the input data tothe chip. These data should be expected in its envi-ronment and then ensure to analyze all output data.Whereas many functions must be performed at therising edge of the clock, others require that the datafrom these units be available several nanosecondsbefore the rising edge of the corresponding clock.


The verification system’s goal is to test the reac-tion of all possible output signals of the gateway. Inparticular, the response of the Vegas–Snoopq mod-ule to various sets of stimuli or input signals. Theydetermine whether the observed behavior is in agree-ment with the chip’s specification. First, the simula-tion has been achieved at two levels: RTL and gate.Second, from a schematic on a Standard Delay For-

Ž . Ž .mat SDF , we use a test bench verilog stimuli toverify the behavior and to outline SDF annotationand timing violation.

5.1.3. SynthesisThe main synthesis steps require no special

knowledge about the synthesis routines. Redundancyremoval and timing optimization as well as timingtestability analysis are all done on the gate-level. Allnetlists of modules are then stitched together ascomponents of this level. Repower routines buildfan-out trees for chiplet interconnections, the bound-ary-scan clock, and control signal. After the entirenetlist has been flattened, the clock trees are gener-ated and remaining fan-out and slew violations arecorrected. In summary, the first synthesis step isrealized with Design Analyzer tool, which outlines anetlist at the gate level providing timing, area andcritical path analysis. Place and route perform thenext synthesis steps giving more information con-cretized by the layout.

5.2. Results

The chip was implemented in CMOS process witha minimum feature size of 0.35 mm. Using thistechnology made it hard to achieve timing conver-gence for some of the fastest interfaces. At thisdesign level, a powerful tool for placing and routingoutlines the layout of the designed systems. Fig. 8gives more details about this implementation results.In addition to Vegas–Snoopq modules, the chipintegrates controller modules, adaptation units andmemory needs, defined below:

v Frame format adapter: allows adapting betweenEthernet frames and ATM cells.

v Vegas–Snoopq : flow and congestion controlmodule at the Ethernet side. It also contains two

Ž .DPRAMs-128=32 Dual Port RAM needed tostock connection parameters.

v ABR module: ensures traffic control and man-agement at the ATM network side. It integratesa DPRAM 182=32, used as FIFO.

v SPRAM-4096=16: memory cache for segmentin transit. There is also a possibility to interfacewith external memory.

Table 1 summarizes implementation parametersfor the ATM–Ethernet interworking system. Thememories, delivered from AMS, are Dual and Single

Fig. 8. Layout of the entire system for interconnection between Ethernet and ATM networks.


Table 1Implementation parameters for the interworking system

2Ž . Ž .Module Lines Columns Area mm Width mm Widthr Min. cycle ConsumptionŽ . Ž .height ns mArMHz

DPRAM 128=32 32 128 1,059,661 1411 1.88 4.00 0.448SPRAM 4096=16 128 512 4,464,072 1604 2.00 6.00 0.391

2 5Interworking system 124 IrO put ports (16 mm (10 gates – 5.00 –

Port RAM. In addition to memories, the chip con-tains, on 16 mm2 of area, 100 thousand gates. Thisresult performs very well an optimized system ac-cording to the application that it turns. Especially,because an efficient searching for the best schedulingof finite state machines and allocation of designunits. The simulations at low levels justify the FSMsspecification from low frequency test until 166 MHzvalue of frequency giving 6 ns as minimum cycle.The system rapidity is limited to 166 MHz caused bythe minimum cycle of the SPRAM 4096=16 mem-

Ž .ory 0.35 m technology .Vegas–Snoopq module takes an important part

in the global load of the interworking system. It usestwo DPRAM 128=32. The first stocks informationfor received data segments. However, the secondloads the main parameters for the received acknowl-edgements. In addition to these DPRAMs, Vegas–Snoopq module is interconnected with the frameformat adapter, the ABR module and the externalmicroprocessor. Consequently, it maintains 79 inputand output ports with active units and 76=4 inter-facing ports with the DPRAMs.

Note: Vegas–Snoopq integrates many arithmeticŽinstances achieving a floating-point division Float–

.Div of bit vectors. This instance leads to use twoconversions from normal bit-vector representation to

Ž .floating point format Std Float and vice versa–Ž .Float Std .–

6. Conclusions

In this paper, we have presented a new techniquecalled Vegas–Snoopq for flow and congestion con-trol in a gateway internetworks. Several mechanismshave been introduced for improving TCP, includinga timeout mechanism, a flow control approach basedon Vegas and Snoop service elements, and a modi-fied slow-start mechanism. This technique is per-

formed by extending Vegas and Snoop protocols atthe gateway, and involves no other changes at anyhosts elsewhere in the interconnected networks. Ve-gas–Snoopq enables to start a TCP connection withslow-start in order to reduce losses. A congestion

Ž .avoidance threshold g has been defined to triggerthe transition from exponential mode to linear mode.This last is adopted by Vegas service element, whichsupervises connection parameters function in the loadon the gateway and the Ethernet network. The trans-mission of segments internetwork is managed by theSnoop service element. In this way, two distin-guished procedures are implemented to process dif-ferently data packets and acknowledgements.

In practice, we have adopted high-level synthesistools allowing the design of complex communicationsystem at several abstraction levels, particularly RTL.Among the advantages of a synthesis tool are theflexibility during design stages and verification in anadvanced design step. The main contribution consistsof translating network and transport-layers softwareto hardware modules. This may ensure more speedand, therefore, allows supporting real time applica-tions.

In future works, we will propose to add an Ex-Ž .plicit Congestion Notification ECN mechanism,

which will improve more reliability against losses ofpackets. Finally, we look to integrate all these mech-anisms on a custom VLSI implemented in CMOStechnology with a minimum feature size of 0.18 mmCMOS.

References

w x1 R. Airiau, J.M. Berge, V. Olivier, J. Rouillard, Du langage a´ `Ž .la modelisation, collection informatique 1990 .´

w x2 M. Allman, A. Falk, On the effective evaluation of TCP,Ž .ACM SIGCOMM Computer Communications Review 29 5

Ž .Oct. 1999 .w x3 A. Bakre, B.R. Badrinath, I-TCP: indirect TCP for mobile


hosts, Proc. 15th International Conference on DistributedŽ .Computing Systems ICDCS , Vancouver, British Columbia,

ŽCanada, IEEE Computer Society Press May 30–June 2.1995 136–143.

w x4 H. Balakrishnan, S. Seshan, E. Amir, R.H. Katz, ImprovingTCPrIP performance over wireless networks, Proc. 1st ACM

Ž .Conf. on Mobile Computing and Networking Mobicom ,Ž .Berkeley, California, USA November 1995 2–11.

w x5 L.S. Brakmo, S.W. O’Malley, L.L. Peterson, TCP Vegas:new techniques for congestion detection and avoidance, Proc.

Ž .ACM SIGCOMM’94 May 1994 24–35.w x6 P. Camurati, P. Prinetto, Formal verification of hardware

correctness: introduction and survey of current research,Ž . Ž .Computer 21 7 July 1988 8–19.

w x7 R. Clauberg, P. Buchmann, A. Herkersdorf, D.J. Webb,Design methodology for a large communication chip, IEEE

Ž . Ž .Design and Test of Computers 17 3 July–September 200086–94.

w x8 S. Floyd, Validation experiences with the NS simulator,Ž .Technical report, ACIRI April 1999 .

w x9 D.D. Gaski, L. Ramachandran, Introducing to high-levelŽ . Žsynthesis, IEEE Design and Test of Computers 11 2 Winter

.1994 44–54.w x10 R.K. Gupta, Y. Zorian, Introducing core-based system de-

Ž . Žsign, IEEE Design and Test of Computers 14 4 Oct.–Dec..1997 15–25.

w x11 V. Jacobson, Congestion avoidance and control. Proc. ACMŽ .SIGCOMM 88 August 1988 314–329.

w x12 R. Jain, A delay-based approach for congestion avoidance ininterconnected heterogeneous computer networks, ACM

Ž . Ž .Computer Communication Review 19 5 Oct. 1989 56–71.w x13 P. Karn, C. Partridge, Improving round-trip time estimates in

reliable transport protocols, ACM Transaction on ComputerŽ . Ž . Ž .Systems TOCS 9 4 November 1991 364–373.

w x14 S. Keshav, S. Morgan, Smart retransmission: performancewith overload and random losses, http:rrwww.cs.att.comrnetlibrattrcsrhomerkeshavrpapersrsmart.ps.Z, 1996. pre-print.

w x15 G. Moretti, Get a handle on design languages, EDN Europe,Ž .54–65 June 2000 .

w x16 R. Ouni, A. Soudani, S. Nasri, M. Abid, K. Torki, R. Tourki,Interoperability system: design and congestion control, Proc.1st European Conference on Universal Multiservice Net-

Ž .works ECUMN , Colmar, France, October 2000, pp. 93–99.w x17 V.N. Padmanabhan, R.H. Katz, TCP fast start: a technique

for speeding up web transfers, Proc. IEEE Globecom’98Internet Mini-Conference, Sydney, Australia, November1998.

w x Ž .18 J. Postel, Transmission control protocol September 1981RFC 793.

w x Ž .19 G. Pujolle, Les reseaux editions Eyrolles 1999 .´ ´w x20 S. Savage, N. Cardwell, D. Wetherall, T. Anderson, TCP

congestion control with a misbehaving receiver, ACM SIG-Ž . ŽCOMM, Computer Communication Review 29 5 October

.1999 71–78.w x21 W.R. Stevens, TCPrIP Illustrated, vol. 1, Addison-Wesley,

Reading, MA, November 1994.

w x22 R.A. Walker, S. Chaudhuri, Introduction to the schedulingŽ . Žproblem, IEEE Design and Test of Computer 12 2 Summer

.1995 60–69.w x23 Z. Wang, J. Crowcroft, Eliminating periodic packet losses in

4.3-Tahoe BSD TCP congestion control algorithm. ACMŽ . Ž .Computer Communication Review 22 2 April 1992 9–16.

R. Ouni received his MSc in PhysicMicroelectronic and his DEA in Ma-teriaux et Dispositif pour l’electro-´ ´nique from the Science Faculty of Mo-nastir, Tunisia, in 1995 and 1997,respectively. Currently, he is a PhD stu-dent. His research interests include com-puter networks, flow and congestioncontrol, interoperability and perfor-mance evaluation.

A. Soudani received his MSc in PhysicŽ .Microelectronic 1996 and his DEA

Ž .1998 from the Science Faculty ofMonastir, Tunisia. He is currently a PhDstudent. His research interests includemultimedia integration in real-time dis-tributed systems. He is working in col-laboration with the industrial LAN teamof CRAN Laboratory.

S. Nasri received his Doctoral degree inAutomatic Control and Computer Engi-neering from the National Institute ofApplied Sciences of Toulouse, France,in June 1985. Since 1988, he has beenan assistant professor in Electrical En-gineering in the National School ofEngineering of Monastir, Tunisia. Hisresearch interest is in the field of Indus-

Ž .trial Local Area Networks ILAN andmultimedia applications. In May 2001,he obtained the Diploma of ‘HabilitationUniversitaire.’ He is currently working

in collaboration with the LSR, the TIMA Laboratories in Grenobleand the CRAN Laboratory in Nancy.

K. Torki is the Technical Director re-sponsible for organizing multiproject run

Žfabrications at CMP Circuits Multi-Pro-.jets Grenoble, France. He is also the

R&D responsible for design-kit devel-opments and CAD support. Previously,he was a research staff member of TIMALaboratory, working on self-checkingcircuits and built-in self-test strategy de-velopments. He is interested in manyareas of design automation includingphysical design, floor planning, timinganalysis, signal integrity and deep sub-

micron design methodologies. K. Torki received his DEA degreeŽand PhD in 1990 from INPG Institut Polytechnique de Grenoble,

.France .


M. Abid is a professor of electricalengineering at Sfax University inTunisia. He holds a Diploma in electri-cal engineering in 1989 from the Uni-versity of Sfax in Tunisia and receivedhis PhD degree in Computer Science in1989 at University of Toulouse inFrance. His research interests includehardwarersoftware codesign, designspace exploration and prototyping strate-gies for real-time systems.

R. Tourki received his BS degree inŽ .Physics Electronics option from Tunis

University in 1970 and his MS and theDoctorat de 3eme cycle in Electronics`from Institut d’Electronique d’Orsay,Paris-South in 1971 and 1973, respec-tively. From 1973 to 1974, he served asmicroelectronics engineer in Thomson-CSF. He received the doctorat d’etat´from Nice university in 1979. Since thisdate, he has been professor in Micro-electronics and Microprocessors with thephysic department, Faculte des Sciences´

de Monastir. His current research interests include digital signalprocessing and hardware software codesign for rapid prototypingin telecommunications.

TCP flow control technique for an interworking interface: hardware implementation

Documents

Transcript of TCP flow control technique for an interworking interface: hardware implementation