37 YeAH-TCP: Yet Another Highspeed TCP
37YeAH-TCP: Yet Another Highspeed TCPAndrea Baiocchi, Angelo P. Castellani and Francesco VacircaINFOCOM Department - University of Roma ”Sapienza”, Via Eudossiana 18, 00184 Roma, Italye-mail: bstract— In recent years, several new TCP congestion controlalgorithms have been proposed to improve TCP performanceover very fast, long-distance networks. High bandwidth delayproducts require more aggressive window adaptation rules, yetmaintaining the ability of controlling router buffer congestion.We define a relatively simple experimental scenario to comparemost current high speed TCP proposals under many metrics:efficiency, internal fairness, friendliness to Reno, induced networkstress, robustness to random losses. Based on the gained insight,we define Yet Another High-speed TCP, as a heuristic attemptto strike a balance among different opposite requirements.Index Terms— High Bandwidth-Delay Product Network, TCP.I. INTRODUCTIONTCP has been defined and refined during the 80’s. Itsstrength and amazing flexibility stems from its longevity andcapacity to accomplish its task even while the network evolvedfrom a 64 kbps backbone to a multi-Gbps core network, withextensive use of wideband wireless access, to say the least.Achieved performance are not optimal, and concern has arisenin the scientific community as to the re-definition of TCPfor use in large Bandwidth-Delay Product (BDP) networks,as provided by optical network core over geographic distanceeven for terrestrial networks 1 . Recent works devoted to thistopic are addressed in Section II.The aim of this work is to report an extensive experimentalmeasurement of most current high speed TCP proposals,evaluated under a number of performance metrics. We considerefficiency in bandwidth exploitation, average packet delay,internal and RTT fairness, friendliness to Reno, robustness torandom losses2 . We set up a single bottleneck test-bed, that caninclude cross traffic and adjustable RTT and random packetloss; this is a trade-off between controllability and significanceof the experimental results. We do not claim ours are definitiveresults, yet they are consistent and lead to sufficient insightthat we felt worth defining a new heuristic for high speed TCP,which we named as Yet Another High-speed (YeAH) TCP.The paper is organized as follows: Section II reviewsrecent literature on new proposals for TCP in high BDPnetworks and gives the motivations for our work. In SectionIII, the description of YeAH-TCP algorithm is provided. Theexperimental testbed is described in Section IV; Section Vreports measurement results. The main conclusions are drawnin Section VI.II. R ELATED W ORKSIn the recent literature, different strategies have been explored to address the problem of TCP in high BDP networks;This work has been partially supported by the Italian Research Ministryunder the PRIN FAMOUS grant.1 A well known instance of large BDP links is satellite.2 This is not so unrealistic, e.g. current optical packet backbones.these can be classified into four different categories: i)Loss-based; ii) Delay-based; iii) Mixed loss-delay-based; iv)Explicit congestion notification.Congestion control algorithms that consider packet loss asan implicit indication of congestion by the network belong tothe first category. All proposals in this category (STCP [1],HSTCP [2], H-TCP [3], BIC [4] and CUBIC [5]) modify theincrease and decrease rule of Reno congestion control to bemore aggressive when they work in high BDP networks.Other proposals (second category) consider delay as anindication for network congestion. A very well known delaybased congestion control algorithm for high BDP network isFAST TCP [6]; it employs an alternative congestion controlalgorithm using both queuing delays and packet losses asindications of congestion in the network. Under normalworking conditions, the congestion window is updated everyRTT and depends on the estimation of the average RTT.In the third category, we find some approaches based ona mix between delay-based and loss-based congestion indications. TCP Africa [7] is a dual state algorithm; the congestionwindow is updated differently in the two operation modes.Specifically the algorithm switches between the “slow” modestate in which the congestion window is updated accordingto Reno algorithm, and the “fast” mode state in which thecongestion window is updated according to HSTCP increaserule. Switching between states is governed by the number ofqueued packets in the bottleneck buffer, inferred through adelay-based approach. As the authors highlight, TCP Africa isaggressive when the pipe is not full and it behaves like Renowhen the full link utilization is achieved.Another approach similar to TCP Africa is the one proposedin [8]. Compound TCP borrows from Africa TCP the idea tobe aggressive only when the capacity of the bottleneck linkis underutilized, by using a different approach: the algorithmkeeps two different variables, the standard congestion windowcwnd and the delay window dwnd; the congestion windowis updated according to the Reno scheme and the number ofoutstanding packets is the sum of the congestion window andthe delay window. The purpose of the delay window is toenable Compound TCP to be more aggressive when the delayvariation is low. This behavior is achieved by enlarging andshrinking the delay window according to the round trip timeestimation.In the last category, there are those solutions (e.g XCP [9])that require explicit signal from the network elements to inferthe congestion of the network. In the remainder of this work,algorithms belonging to this category are not considered sincetheir development requires the cooperation of router and hencea modification of today Internet.Besides, we do not consider cross-layer solutions involvinge.g. AQM; we assume congestion control relies only on endto-end mechanisms.As shown in this section, several proposals exist to overcome the problem of TCP in high BDP network. However,
38recent discussions on the end2end mailing list [10] andseveral experimental and simulative works ([11], [12] [13])reveal that there is no agreement on the best congestioncontrol paradigm for high BDP networks. An algorithm, whoseperformance are optimal in a particular scenario, may performunsatisfactorily in other scenarios. Moreover, different testbedslead to different results due to minimal differences in thealgorithm implementation or in the network scenario design.Besides it is not clear, which are the metrics that should beconsidered to evaluate a new congestion control algorithm. Abig effort in this direction has been carried out by IRTF in[14] to standardize the methods and the metrics for congestioncontrol evaluation.In our opinion, the new proposals for TCP in high BDPnetworks are not evaluated correctly since it is often forgottenthat one of the main characteristic should be the capabilityof the algorithm to avoid congestion in the network and notonly the capability to achieve the full link utilization. I.e.,an important issue that is not payed enough considerationin most performance evaluation papers is if the proposedalgorithm is optimal from a congestion controller point ofview. If we consider a single STCP flow in a single bottleneckscenario, it is able to achieve the full link utilization infew round trip times, since its increasing rule is aggressive.This leads to multiple losses, whenever the bottleneck linkbuffer has been filled up, that can be rapidly recovered byan efficient loss recovery procedure, such as SACK TCP.In opposition, standard TCP is slow in reaching the steadystate behavior in large BDP network since it increases itscongestion window by one packet per RTT, but from the pointof view of a loss-based congestion controller it is optimal,since it probes the network with one packet more per roundtrip time, which is the minimum increment rate adapted to thedelay of the feedback signal. Nowadays, the large diffusion ofTCP congestion control preserves network health for legacyReno traffic and new-generation application with real-time orinteractive requirements. Instead the lack of congestion controldesign in new transport protocol can cause network instabilityand non-negligible degradations.In this context, the purpose of our work is twofold. On onehand, we propose yet another congestion control paradigm thatis able to fully exploit the capacity of high BDP links withoutloosing its congestion control capabilities. On the other hand,results obtained with yet another experimental testbed, canbe used by other researchers to gain a deeper insight in theevaluation of other existing proposals.In the experimental evaluation section, the number ofcongestion controllers has been creamed off to make theobtained results easily readable; we compare CUBIC, HSTCP,H-TCP, Africa, Compound TCP and our proposal, namelyYeAH-TCP. FAST TCP has not been considered since thealgorithm code is not publicly available; STCP has not beenconsidered since it has been widely shown that it is highlyRTT unfair (see for example [11]). Since CUBIC TCP is thenew candidate algorithm for Linux TCP default setting and itcan be considered the evolution of BIC, BIC results are notshown.III. Y E AH: ALGORITHM DESIGNIn the design of YeAH-TCP we considered various goals:1) Network capacity should be exploited efficiently. Thisis the most obvious goal, which can be achieved bymodifying the congestion window update rules; asdescribed later, YeAH TCP can exploit anyone of theincrement rules of other proposals (e.g. STCP, H-TCP,etc.).2) The stress induced to the network should be less orequal than that induced by Reno TCP. Most of thehigh speed TCPs induce congestion events frequentlyat the bottleneck router and the number of packetdrops in a single congestion event are significantlyhigher as compared to standard Reno congestion control,degrading the performance achieved by other trafficsharing the path. Further, queuing delays and delay jitterare also adversely affected.3) TCP friendliness with Reno traffic. A “politically”acceptable algorithm should be able to compete fairlywith Reno flows, avoiding starvation of competing flows,and simultaneously exploiting the link capacity.4) The algorithm should be internally and RTT fair.5) Performance should not be substantially impaired by noncongestion related (random) packet loss events; randompacket loss cannot be ruled out even in case of highspeed optical backbones. Reasonable values of this lossdepend on the technological context, but we verify thateven a loss rate in the order of 10 7 can give rise tosensitive performance degradation.6) Small link buffers should not prevent high performance.It is not feasible to design buffer size equal to thebandwidth-delay product in high BDP links as requiredby standard Reno congestion control [15]. This goal canbe achieved by adopting a decrease policy in case ofpacket loss similar to the Westwood algorithm [16].YeAH-TCP attempts to address all the aforementionedissues. It envisages two different modus operandi: “Fast” and“Slow” modes, like Africa TCP. During the “Fast” mode,YeAH-TCP increments the congestion window according to anaggressive rule (we chose STCP rule, since it is very simple toimplement). In the “Slow” mode, it acts as Reno TCP.The state is decided according to the estimated numberof packets in the bottleneck queue. Let RT Tbase be theminimum RTT measured by the sender (i.e. an estimate of thepropagation delay) and RT Tmin the minimum RTT estimatedin the current data window of cwnd packets. The currentestimated queuing delay is RT Tqueue RT Tmin RT Tbase .From RT Tqueue is possible to infer the number of packetsenqueued by the flow as: cwndQ RT Tqueue · G RT Tqueue ·(1)RT Tminwhere G is the goodput. We can also evaluate the ratiobetween the queuing RTT and the propagation delay L RT Tqueue /RT Tbase , that indicates the network congestionlevel. Note that RT Tmin is updated once per window of data.If Q Qmax and L 1/ϕ, the algorithm is in the “Fast”mode, otherwise it is in the “Slow” mode. Qmax and ϕ aretwo tunable parameters; Qmax is the maximum number ofpackets a single flow is allowed to keep into the buffers. 1/ϕis the maximum level of buffer congestion with respect toBDP. During the “Slow” mode, a precautionary decongestionalgorithm is implemented3: whenever Q Qmax , the congestion window is diminished by Q and ssthresh set to cwnd/2.Since RT Tmin is computed once per RTT, the decongestiongranularity is one RTT.3 As it will be explained in the following, the decongestion is employed onlywhen the YeAH-TCP is not competing with Reno flows.
39Considering the case that a single YeAH-TCP competes forthe bottleneck link, Q is an estimate of the excess amountof packets with respect to the minimum cwnd required toexploit the available bandwidth. This amount of packetscan be removed from the actual congestion window withoutdegrading the goodput. When the number of competing flowsincreases, every flow attempts to fill the buffer by the samenumber of packets (at maximum Qmax ) independently of theperceived RTT, achieving the internal RTT fairness. Moreoverthe precautionary decongestion prevents the bottleneck queuefrom building up too much, reducing queuing delays anddiminishing packet losses due to buffer overflow. As shown in[17], the precautionary decongestion is optimal only when theflows that implement it do not compete with “greedy” sources,such as Reno TCP. When competing with “greedy” flows, theprecautionary decongestion makes the conservative flow losecapacity, since it releases bandwidth to the greedy sources.To avoid unfair competition with legacy flows, YeAH-TCPimplements a mechanism to detect if it is competing with“greedy” sources. Consider the case of competition with Renoflows, that do not implement the queue decongestion; whenQ Qmax YeAH-TCP attempts to remove packets from thequeue, the queuing delay increases on because Reno flows are“greedily” filling up the buffer. In this case, YeAH-TCP willstay hardly ever in “Fast” mode state and frequently in “Slow”mode. On the contrary, with non greedy competing flows(e.g. flows implementing the precautionary decongestion), theYeAH algorithm will cause a state change from “Fast” to“Slow” whenever buffer content builds up above Qmax andback as soon as the precautionary decongestion becomes effective. This different behavior makes it possible to distinguishbetween the two different competition circumstances, countingthe number of RTTs that the algorithm is in the two states. Tothis aim, two counting variables are defined: countreno andcountf ast . countf ast represents the number of RTTs in “Fast”mode. countreno is an estimate of the value of the congestionwindows of competing Reno flows. The decongestion takesplace only during the “Slow” mode and if cwnd countrenoto avoid that the congestion window decreases below theestimated value of the Reno flows congestion window. At thestart-up countreno is initialized to cwnd/2, it is incrementedby one every RTT in ”Slow” mode and, when a packetloss is detected countreno is halved. The variable is resetto the current cwnd/2 whenever countf ast is greater thana threshold, indicating that the flow is competing with othernon-greedy flows. At the same time countf ast is reset to 0.Figure 1 depicts two examples of the evolution of YeAH-TCP100050000cwnd YeAH 1cwnd YeAH 2Queue100200300Time (s)400500600100050000cwnd YeAH 1cwnd Reno 1Queue100200300Time (s)400Fig. 1. YeAH-TCP congestion window evolution.500600congestion window when competing with a YeAH-TCP flow(upper plot) and when competing with a Reno flow (lowerplot). In the first case, when the second YeAH-TCP flow starts,the two flows converge steeply towards the same congestionwindow. In the second case (lower plot), when the Reno TCPflow starts, the YeAH-TCP decrements the congestion windowtill the moment it gets aware to compete with a “greedy”flow, i.e. until cwnd becomes less than countreno . From thismoment on, the two flows share the bandwidth in the Renoway.Last issue is what happens in case of packet losses. When aloss is detected by three duplicate ACKs, the current estimateof the bottleneck queue Q, can be exploited to find thevalue of packets that should be removed from the congestionwindow to empty the bottleneck buffer, yet leaving the pipefull. This rule is similar in principle to the one used byWestwood TCP [16]. This rule permits to obtain the full linkutilization after a loss, for every value of the bottleneck buffersize and in case of losses independent of the congestion ofthe network. In case of three duplicate ACKs, when YeAHTCP does not compete with Reno flows4 , cwnd is decreasedby min{max{cwnd/8, Q}, cwnd/2} segments. If YeAH-TCPcompetes with Reno flows, the congestion window is halved.IV. E XPERIMENTAL T ESTBEDTo investigate the effectiveness of the new congestioncontrol proposal, a testbed has been designed and implemented. Its primary scope was to recreate a realistic high-speedlong-distance network environment to test congestion controlalgorithms. The testbed development platform is based uponthe GNU/Linux operating system, with three PCs running amodified version of the 2.6.16.2 kernel release. The physicalnetwork topology of the connections is based on 1000BaseTXphysical connections, between the hosts. The logical topologyof the testbed is depicted in Figure 2. Host 1 and host 2RTT1BHost 1CRouter RHost 2Host 3RTT2Fig. 2. Testbed logical topologyare connected to router R with two full duplex 1Gbps links;the link between router R and host 3 is the bottleneck linkand its capacity C can vary between 10kbps and 500Mbps;in the experimental results section (Section V) C has beenfixed to 500 Mbps and the data packet size fixed to 1500bytes. The RTT between host 3 and host 1 is RT T1, whereasthe RTT between host 3 and host 2 is RT T2 . Both RTTscan varies between 12ms and 480ms independently. Therouter buffer B is always configured as a fraction of theBDP C·min(RT T1 , RT T2 ); where not specified, ssthresh isunlimited and the limited slow start algorithm [18] is enabled.The advertised window is set to high values so not to limitthe value of the TCP sender congestion window. A cross webtraffic has been generated, by letting host 3 be a web server anda specific fourth PC (different from host 1, 2 and 3 in Figure2) simulates a population of clients. Web traffic is generated4 This fact is recognized by comparing the number of consecutive RTTsspent in “Slow” mode up to the current time with a threshold.
40according to the SURGE model [19]; the average web trafficload is 4 Mbps. Where not specified, every experiment hasa fixed duration of 600s and each measurement point is theaverage of at least three experiments.It is worth to pinpoint that to evaluate the congestioncontrol algorithm it is required that the bottleneck link is notdirectly connected to the sender. In fact, whenever the outgoingnetwork interface has been filled by the sender, the congestionwindow stops to increase (disabling the congestion control)and the sender transmits at full rate.The Linux TCP/IP internetworking stack has been modifiedto make it fully RFC compliant; Linux implementation, in fact,does not always respect RFCs as reported in [20]. Moreover,Africa TCP and Compound TCP have been implemented inthe Linux kernel to test their performance. A patch for Linuxkernel is publicly available at [21].RT T icaCUBICHS-TCPRT T 140.00001849900.0000293257RT T 6500.00002966270.0000041152TABLE IB UFFER OVERFLOW PACKET LOSS PROBABILITY.In Table I the packet loss probability induced in thebottleneck buffer is reported for different values of RTT. Adash sign means that no
In the design of YeAH-TCP we considered various goals: 1) Network capacity should be exploited efficiently. This is the most obvious goal, which can be achieved by modifying the congestion window update rules; as described later, YeAH TCP can exploit anyone of the inc
3622/udp ff-lr-port FF LAN Redundancy Port 4120/tcp Bizware Production Server 4121/tcp Bizware Server Manager 4122/tcp Bizware PlantMetrics Server 4123/tcp Bizware Task Manager 4124/tcp Bizware Scheduler. 4125/tcp Bizware CTP Serve
Cisco WAE 7326 90Mbps 6000 TCP 155Mbps 7500 TCP Cisco WAE 7341 Medium Data Center Entry Level (4-8Mbps) 4Mbps 8Mbps 800 TCP Cisco WAE 512 Cisco WAE 612 Cisco WAE 20Mbps 1500 TCP Small Branch Office 4Mbps 250 TCP 500 TCP Cisco ISR 2800/3800 NME 502 Cisco ISR 3800 NME 522 PRICE Cisco ISR 2811 NME 302
623 UDP ASF Remote Management and Control Protocol (ASF-RMCP) Official 625 TCP Open Directory Proxy (ODProxy) Unofficial 631 TCP UDP Internet Printing Protocol (IPP) Official 631 TCP UDP Common Unix Printing System (CUPS) Unofficial 635 TCP UDP RLZ DBase Official 636 TCP UDP Lightweight Directory Access
iv Routing TCP/IP, Volume II About the Author Jeff Doyle, CCIE No. 1919, is vice president of research at Fishtech Labs. Specializing in IP routing protocols, SDN/NFV, data center fabrics, MPLS, and IPv6, Jeff has designed or assisted in the design of large-scale IP service provider and enterprise net-works in 26 countries over 6 continents.File Size: 7MBPage Count: 158Explore furtherRouting TCP/IP Volume 1 PDF Download Free 1578700418ebooks-it.orgDownload [PDF] Routing Tcp Ip Volume 1 2nd . - Usakochanwww.usakochan.netCcie Routing Tcp/ip Vol 1(2nd) And 2 Free . - Ebookeewww.ebookee.netJeff Doyle eBooks Download Free eBooks-IT.orgebooks-it.orgCCIE Professional Development Routing TCP . - Academia.eduwww.academia.eduTcp ip volume 1 jeff doyle pdf - AKZAMKOWY.ORGakzamkowy.orgRecommended to you b
Reaching Beyond the Local-Area Network—the Wide-Area Network 10 TCP Large Window Support 10 TCP Selective Acknowledgment Support 14 2. TCP/IP Protocol Suite 15 Introducing the Internet Protocol Suite 15 Protocol Layers and the OSI Model 16 TCP/IP Protocol Architecture Model 17 How the TCP/IP Protocols Handle Data Communications 22 Contents iii
135 TCP RPC Endpoint Mapper 137 UDP NetBIOS Name Service 139 TCP NetBIOS Session (SMB) 389 UDP/TCP LDAP 445 TCP SMB over TCP 3268 TCP Global Catalog Search. Solution Guide citrix.com Kerberos Multi Domain Authentication for ActiveSync 8 Prerequisites DNS should be configured to resolve all the domains.
traces.zip; see earlier footnote) to study TCP behavior in the rest of this lab. 3. TCP Basics Answer the following questions for the TCP segments: 4. What is the sequence number of the TCP SYN segment that is used to initiate the TCP connection between the client computer and gaia.cs.umass.edu? What is it
Alfredo López Austin (1993:86) envisioned the rela - tionship between myth, ritual, and narrative as a triangle, in which beliefs occupy the dominant vertex. They are the source of mythical knowledge
