TCP Congestion Control

-1-
Abstract
TCP Congestion Control comprises of TCP Vegas, which is a new design for TCP that
includes a modifed retransmission strategy (compared to TCP Reno) that is based on
fnegrained measurements of the roundtrip time (RTT) as well as new mechanisms
for congestion detection during slowstart and congestion a!oidance" This paper
ta#es a fresh loo# at the design of TCP Vegas and attempts to shed light on the
ad!antages (and disad!antages) of the inno!ations introduced by TCP Vegas" TCP
Reno$s congestion detection and control mechanisms use the loss of segments as a
signal that there is congestion in the networ#" TCP Reno has therefore no mechanism
to detect the incipient stages of congestion before losses occur and hence cannot
pre!ent such losses" Thus, TCP Reno is reactive, as it needs to create losses to fnd
the a!ailable bandwidth of the connection" %n the contrary, TCP Vegas$s congestion
detection mechanism is proactive, that is, it tries to sense incipient congestion by
obser!ing changes in the throughput rate" &ince TCP Vegas infers the congestion
window ad'ustment policy from such throughput measurements, it may be able to
reduce the sending rate before the connection e(periences losses"
&ince TCP Vegas is essentially a combination of se!eral di)erent techni*ues, each
e!o#ing considerable contro!ersy on its own, much of pre!ious wor# either
concentrated on discussing and e!aluating a particular mechanism in isolation or
tried to characteri+e the o!erall beha!ior of TCP Vegas" The *uestion, howe!er, which
of the techni*ues incorporated in TCP Vegas is responsible for the performance gains
reported in, remains unanswered so far" To answer this *uestion, we decompose TCP
Vegas into its indi!idual algorithms and assess the e)ect of each of these algorithms
on performance"
,ntroduction-
Purpose
-2-
A new TCP implementation called Vegas that achie!es between ./0 and
1/0 better throughput and oneffth to onehalf the losses, when compare
with TCP Reno" Vegas is an alternati!e implementation that interoperates
with any other !alid implementation of TCP, and all changes are confned
to the sending side"
&cope-
,n the late 2/s, the ,nternet su)ered a congestion collapse
The inno!ati!e techni*ues of TCP Vegas ha!e been the sub'ect of much
debate in recent years" &e!eral studies ha!e reported that TCP Vegas
pro!ides better performance than TCP Reno" 3owe!er, the *uestion which
of the new techni*ues is responsible for the impressi!e performance gains
remains unanswered so far"
This paper presents a detailed performance e!aluation of TCP Vegas" 4y
decomposing TCP Vegas into the !arious no!el mechanisms proposed and
assessing the e)ect of each of these mechanisms on performance, we
show that the reported performance gains are achie!ed primarily by TCP
Vegas$s new techni*ues for slowstart and congestion reco!ery" TCP
Vegas$s inno!ati!e congestion a!oidance mechanism is shown to ha!e
only a minor in5uence on throughput" 6urthermore, we fnd that the
-3-
3os
t
3os
t
3os
t
Congestion7
Pac#et
drops77
8at
a
9
Retransmission
s
:ore
8rops777
Collap
se
congestion a!oidance mechanism e(hibits fairness problems e!en if all
competing connections operate with the same round trip time"
Proposed &ystem features-
,n order to a!oid unnecessary delay and minimi+e the 5aws that e(isted in
the pre!ious system a follow up module for the e(isting system has been
designed"
Vegas implementation uses the idea to measure and control the amount of
e(tra data that a connection has in transit, where e(tra data means data
that would not ha!e been sent if the bandwidth used by the connection
e(actly matches tha a!ailable bandwidth of the lin#" Vegas;s goal is to
maintain the <right< amount of e(tra data in the networ#" %b!iously, if a
connection is sending too much e(tra data, it will cause congestion= if it;s
sending too little e(tra data, it cannot respond rapidly enough to transient
increase in the a!ailable bandwidth"
This algorithm is not in e)ect during slowstart and its implementation is
as follows-
>" 8efne a gi!en connection;s BaseRTT to be the RTT of a segment when
the connection is not congested= in practice it sets BaseRTT to the
minimum of all measured RTTs= it is commonly the RTT of the frst
segment sent by the connection, before the router *ueues increase due to
tra?c generated by this connection" ,f we assume we are not o!er5owing
the connection, the e(pected throughput is gi!en by- Expected =
WndowSize / BaseRTT, where WindowSize is the si+e of the current
congestion window, which we assume to be e*ual to the number of bytes
outstanding"

@" Calculate the current Actual sending rate recording how many bytes are
transmitted between the time that a segment is sent and its ack is
recei!ed and its RTT, and di!iding the number of bytes transmitted by the
-4-
sample RTT" This calculation is done once per roundtrip time"

A" Then compare Actual to Expected and adjust the window accordingl"
Bet !i" = Expected # Actual" Cote that !i" is positi!e or +ero by defnition,
since Actual $ Expected implies that we ha!e to change BaseRTT to the
latest sample RTT" Also defne two thresholds a and %, such that, a & %,
roughly corresponding to ha!ing too little and too 'uch e(tra data in the
networ#, respecti!ely" Dhen !i" & a, (egas increases the congestion
window linearly during the ne(t RTT, and when !i" $ %, (egas decrease
the congestion window linearly during the ne(t RTT" The congestion
window is le)t unchanged when a & !i" & %"
,ntuiti!ely, the farther away the actual throughput gets from the e(pected
throughput, the more congestion there is in the networ#, which implies
that the sending rate should be reduced" The % threshold triggers this
decrease" %n the other hand, when the actual throughput rate gets too
close to the e(pected throughput, the connection is in danger of not
utili+ing the a!ailable bandwidth" The a threshold triggers this increase"
The o!erall goal is to keep %etween a and % extra%tes in the network"
-5-
3ardware Re*uirements-
>" Pentium ,,, Processor with E 2// :h+ &peed
@" >@2 :4 RA:
A" >/ F4 388
." >.G Color :onitor
H" >".. :4 688
&oftware Re*uirements-
-6-