TCP Smart Framing: a Segmentation Algorithm to
Improve TCP Performance
Marco Mellia, Michela Meo, Claudio Casetti
Dipartimento di Elettronica, Politecnico di Torino, 10129 Torino, Italy
?mellia, michela, email@example.com
Abstract. In this paper we propose an enhancement to the TCP protocol, called
TCPSmart Framing,orTCP-SFforshort, thatenablestheFastRetransmit/Recovery
algorithm even when the congestion window is small. TCP-SF is particularly ef-
fective for short-lived flows, as most of the current Internet traffic is. Without
modifying theTCPcongestioncontrol based ontheadditive-increase/multiplicative-
decrease paradigm, TCP-SF adopts a novel segmentation algorithm: while Clas-
sic TCP starts sending one segment, a TCP-SFsource is allowed to send an initial
window of 4 smaller segments, whose aggregate payload is equal to the connec-
Tahoe to SACK, and requires modifications to the server behavior only.
Analytical results, simulation results, as well as testbed implementation measure-
ments show that TCP-SF sources manage to outperform Classic TCP in terms of
???. This key idea can be implemented on top of any TCP flavor, from
1 Introduction and Work Motivation
Balancing greediness and gentleness has always been the distinctive feature of conges-
tion control in the TCP protocol . Mindfulof the presence of othertraffic sharingthe
same network resources, TCP tries to grab as much bandwidth as possible, eventually
causing congestion and data loss. Data lost by TCP is used as congestion signal, and
cause the source to slow down its transmission rate. Thus, lost data can actually be seen
as bandwidthused to controlandregulatethe network,since everysegmentthe network
discards is an indication that a TCP source has been congesting the network and should
temporarily back off.
Thisschemehas beensuccessfullyemployedoverthe years,whilethe trafficpattern
has shifted from long file transfers and short, persistent connection,typical of terminal-
emulation traffic, to the ”Click-and-Run” paradigm found in Web interactions .
A recent paper on TCP congestion control  listed four “golden rules” for a well-
formed congestioncontrol forTCP connections. Specifically, a TCP congestion control
should: i) exhibit additive increase and multiplicative decrease behavior of the con-
gestion window; ii) use retransmission timeouts to slow down the sending rate during
?This work was supported by the Italian Ministry for University and Scientific Research under
the PlanetIP project and the CERCOM project. A preliminary version of this paper appeared
in IEEE Globecom 2001.
highly-congested spells; iii) initially probe the available bandwidth using the exponen-
tial window increase typical of the Slow Start algorithm; iv) clock the sending rate
based upon the return of ACKs.
In this paper, we propose a new approach to data segmentation in the early stages
of Slow Start that adheres to the four guidelines listed above and, at the same time,
addresses the nature of today’s Internet traffic: short, spotty client-server interactions
between a Web client and a Web server. We will refer to this variant of TCP as “TCP
Smart Framing”, or TCP-SF for short.
As will be detailed below, we advocate an increase in the numberof segments trans-
mitted by a TCP source, without increasing the amount of application data actually
sent in the congestion window. This will be done whenever the congestion window is
”small”, i.e., at the beginning of each Slow Start phase, and in particular at the flow
The main observation is that TCP’s congestion control is only marginally driven by
the rate at which the bytes leaves the source but, rather, by the rate at which segments
(and their respective ACKs) are sent (or received) at the source.
TCP infers that a segment is lost whenever one of the following two events occurs:
a Retransmission Time Out (RTO) expiration, or the arrival of three duplicate ACKs
that triggers the Fast Retransmit (FR) algorithm. Of these two events, RTO is the most
undesirable one as the RTO period is usually much larger than the Round Trip Time
(RTT) Indeed, regardless of the actual amount of bytes transmitted, a coarse RTO ex-
piration can be prevented only if enough segments are sent in the transmission window
(i.e., at least three more following the lost segment). This situation can occur only if i)
the congestionwindow is largerthat 4
is long enough to allow the transmission of at least 4 back-to-back segments (i.e., it is
not a so-called short-lived flow).
Also, it should be pointed out that repeatedly forcing a short-lived connection into
RTO often results in excessive penalty for the connection itself, that would otherwise
be finished in few more segments, rather than in actual network decongestion. Since
today’s Internet traffic is heavily represented by short-lived connections , the need
is felt to address their requirements in the design of TCP’s congestion control.
While Classic TCP1starts sending one segment, in our scheme a TCP-SF source
is allowed to send
ciated to the connection. Thus, the resulting network load is, byte-wise, the same of a
Classic TCP connection (except for the segmentation overhead). The ACK-driven win-
dow increase law employed by TCP-SF affects the amount of data per segment, rather
than the numberof segments, until a threshold is reached, after which TCP-SF resumes
the classic behavior. The Classic TCP algorithms (Slow Start, Congestion Avoidance,
Fast Retransmit, Fast Recovery) are not otherwise affected. However, the modification
introduces a number of key advantages:
??? (Maximum Segment Size) and ii) the flow
??segments, whose aggregate payload is equal to the
– the lengthy first-window RTO (set to 3 seconds) is no longer the only outcome if a
loss occurs at the onset of a connection;
1unless otherwise specified, by “Classic” TCP we refer to any TCP version currently imple-
mented in standard TCP stacks (i.e., TCP Tahoe , TCP Reno , TCP NewReno , TCP
– when Delayed ACKs are employed and the congestion window is 1 segment large,
the receiver has not to wait for 200 ms before generating an ACK; several current
TCP implementation start a connection with a window of 2 segments, a widely-
employed acknowledged workaround to the Delayed ACK initial slowdown;
– the RTT estimate,which is updateduponthe receptionofeveryACK,andis usedto
set the retransmission timer, improvesits accuracy early on, thanks to the increased
number of returning ACKs in the first window already;
– short-lived flows, for which the completion time is paramount,are less likely to ex-
perience a coarse RTO expiration, since the number of transmitted segments grants
a bigger chance of triggering FR;
– shorter segments can exploit pipelining transmission, completing the transfer in
a shorter time because of the store-and-forward mechanism at the routers; this is
especially useful in slow links;
– not requiring any contributionfrom the receiver, the scheme can quite easily be de-
ployed on a source-only basis; furthermore, it can equally benefit well-established
Classic TCP flavors, such as TCP Reno, NewReno, SACK, and also works coupled
with ECN (Early Congestion Notification).
2 TCP Smart Framing
As is well known, when the TCP congestion window size (??
segments, TCP has no other means to recover segment losses than by RTO expiration.
Indeed, since ACK transmission is triggered by the reception of a segment, the re-
ceiver has no chance to send three duplicated ACKs when the congestion window size
is smaller than foursegments. Being the time to recovera loss by RTO expirationmuch
longer than the time needed by FR, this behavior deteriorates TCP performance, espe-
cially when connections are short-lived. In particular, when the flow length is shorter
than 7 segments (i.e., about 10 Kbytes using a 1460-bytes MSS), there are no chances
forthe transmitterto triggera FR. Note that if the Delayed-ACK optionis implemented,
the flow must last more than 10 segments.
In the scheme we propose, TCP-SF, we enhance TCP behavior in the operating
FR possible, as for example at the beginning of each Slow Start phase. The region in
which we enhance TCP behavioris shadowed in Figure 1 which shows the dynamics of
??) is smaller than four
?? ??. This region is commonly known as the small window regime.
TCP-SF is based the followingidea: increasingthe upstream flow of ACKs bysend-
ing downstream a larger number of segments whose size is smaller than the
While maintainingunchangedthe amountof datainjectedinto the pipe,a largernumber
of segments receivedat the otherend triggers a largernumberof ACKs in the backward
channel and thus a larger probability that the transmitter can recover losses without
waiting for the RTO to expire. In other words, this procedure gives the transmitter the
chance to obtain more feedback about what is happening at the receiver. Increasing the
number of ACKs will therefore enable FR when the congestion window is smaller than
four segments; in particular any flow larger than
and help the RTT estimation algorithm to converge quickly to the correct values of the
RTO, thus alleviating the first RTO penalty of 3 seconds.
? will benefit from this;
TCP-SF when congestion window size is equal to
???? growth and small window region (on the left). Error recovery for Classic TCP and
??? bytes (on the right).
We now illustrate our approach by means of an example, using
done in the rest of the paper. Upon the onset of a connection, the congestion window
size is equal to one segment, i.e.,
gets no information back, and waits for the RTO to expire before sending the segment
again; this behavior can be observed in the left part of Figure 1. Now, if instead of
three duplicated ACKs, as shown in the right part of Figure 1.
Since the enhancement introduced by TCP-SF is needed when only RTO can be
used to detect segment losses, we only activate the smart framing option when the
window size is smaller than the threshold
TCP behavior (i.e., segment size equal to
large enough to enable FR. Of course, this behaviorapplies both at connectionstart and
whenever the congestion window is shrunk to a size smaller than
Let us now elaborate a bit on the small-segment option. We define
initial congestion window size in bytes2We consider two possible behaviors:
??, as will be
??? bytes. If this segment is lost, the transmitter
??? bytes long segment, the transmitter sends four segments whose size
?? ???, the loss of the first segment can be recovered by FR after the reception of
???, and we switch back to Classic
???) as soon as the congestion window is
– Fixed-Size (FS-) TCP-SF. When
?? ??? ?? ??
???, the segments size is equal to
???; otherwise, the segment size is equal to
– Variable-Size (VS-) TCP-SF. The initial segments size is equal to
segment size is equal to
the amount of data sent by the TCP-SF is equal to the one sent by a Classic TCP.
After some calculation, we obtain
?? ??? ????
???, the segment size is increased by a factor
?, until the
???. The value of
? can be determined by imposing that
Given that the FR algorithm is triggered by the reception of 3 DUP-ACKs, we sug-
???be set to 4 ???.
2We consider a TCP implementation where initial window (IW) and loss window (LW), as
defined in , take the same value.
One advantage of using TCP-SF with fixed-size segments relies in its simplicity:
two segment sizes only are possible, either
head introduced increases with
ments, TCP-SF keeps the overhead constant but a more careful implementation is re-
quired to deal with variable-size segments.
Let us point out and summarize some critical issues related to the implementation
???. However, the over-
????. On the contrary, when using variable-size seg-
– The degree of aggressiveness of TCP-SF is the same as other classical versions of
TCP. In fact, the evolution of
network are unchanged.
– The proposed enhancement can be applied to any version of TCP, since they all
adopt the same mechanism to detect segment drops. Moreover, it is suitable to be
TCP-SF willbeabletotriggerFRas soonas thereceiverdisablestheDelayed-ACK
feature when out of order segments are received .
– The implementation of TCP-SF is extremely simple. It requires to slightly modify
the transmitter behavior while maintaining the receiver unchanged. This modifica-
tion translates into a few lines of code in the TCP stack.
– The main disadvantage is that TCP-SF increases the overhead of a factor equal to
the segment size reduction factor; i.e., using four segments per
SF overhead is four times the Classic TCP overhead. In particular, when no losses
occur,FS-TCP-SF will send28 small-size segmentsbeforeswitchingbackto large-
size segments. VS-TCP-SF, on the contrary, sends 12 segments. Instead, Classic
TCP always sends 7 segments. It should also be pointed out that a larger numberof
segments can nominally slow down router operations.
?? ?? as well as the amount of data submitted to the
???, the TCP-
3 Throughput gain
In this Sectionwe analyticallyevaluatethe gainobtainedby employingTCP-SF instead
of other classic versions of the protocol. The gain is expressed in terms of throughput
and is derived giventhe network conditions,i.e., given a value of the average round-trip
time and of the segment loss probability.
We restrict our analysis to the working region of TCP where TCP-SF acts on seg-
ment size in order to improve the protocol performance; i.e., the small window regime.
The region is defined by the window size ranging between 1 and
region, all the TCP versions behave the same, and no further gain can be achieved by
TCP-SF. Forsimplicity,we assumethatthe congestionwindowgrowsalways according
to the Slow Start algorithm, and that the segment transmission time due to the store and
forward mechanism implemented in the routers is negligible with respect to the RTT.
In order to describe the behavior of Classic TCP and of TCP-SF for small values
of the window size, we develop two models based on the TCP state machine which are
presented in the next two Subsections. The idea is to evaluate the time spent (and the
data sent) by the different versions of TCP in the small window working region. For
this purpose, a continuously backlogged source is assumed.
???. Out of this
For simplicity, we consider the TCP-SF option with fixed segment size equal to
? ??? and
?4. Similar conclusions can be drawn for the variable segment
3.1Model of Classic TCP
In this Subsection we present the State Machine (SM) which describes the behavior of
classic versionsofTCP whenthe windowsize is comprisedbetween1 andthe threshold
time spent in each state, which will be introduced later.
The state diagram of the classic TCP SM is shown in the left part of Figure 2. At
the connection set up or when Slow Start is entered, the window size is equal to 1, in
the SM this is represented by state 1. One segment is transmitted and, after a round-trip
time, if the segment was not lost, TCP increases the window size to 2. Correspondingly,
the SM moves from state 1 to state 2 with probability
loss probability.Similarly, the transition fromstate 2 to state 4 has probability
ration is lost again, the SM remains in
the retransmitted segment is successfully delivered, the SM leaves state
state 2, because the new ACK makes the window slide and widen.
We now want to evaluate the average time
state 1 to state 4, since from that moment on the behavior of TCP-SF is the same as the
Classic TCP. From the SM, we observe all the possible paths between 1 and 4 and we
evaluate their probability. We then weight each path with its duration which is the sum
of the times needed to visit all the states along the path.
The duration of a visit to states 1 and 2 is equal to the round-trip time RTT; a visit
account the backoff mechanism,
?4. When developing the SM, we focus on the state changes neglecting the
? is the segment
?? represents the timeout. If the segment retransmitted after timeout expi-
?? and the backoff mechanism applies. When
?? and enters
?needed by the SM to move from
??, instead, takes a time equal to the average timeout duration,
?. Taking into
? is the average timeout as in (1) and
? is the round trip time.
???? ???? ?????
The infinite sum accounts for losses occurring in state 2.
In a similar way, it is possible to compute
transmitted in the small window region. One, two and zero segments are transmitted in
states 1, 2 and
?, the average number of segments
Fig.2. State machine which describes the behavior of Classic TCP (on the left) and FS-TCP-SF
(on the right) when the window size ranges between 1 and
state 2 when some losses occur.
We can now compute the throughput in the small window region as,
???? ????? is the average number of segment successfully transmitted in
3.2 Model of TCP Smart Framing
The state machine diagram which describes FS-TCP-SF behavior is shown in the right
plot of Figure 2.
When entering Slow Start the congestion window size is equal to
SF transmits 4 small segments. In the SM, we represent this situation by state 4.
When some losses occur, TCP-SF can either enter FR or RTO; this choice depends
on the loss pattern,and in particularit changes on the basis of which segmentwithin the
window is the first one to be lost. In order to distinguish different cases, we introduce
in the SM four states labeled as
algorithm entered by TCP when the first lost segment is the
In this case, FR can be entered only if the following three segments are successfully
delivered. Therefore, the transition probability from state 4 to
?represents the FR
?represents the case in which the first segment of the window is lost.
?is equal to
In case the second segment of the window is lost, the ACK of the first segment
makes the window slide and widen so that a total number of four segments are trans-
mitted after the lost one. Therefore, FR is entered if three out of the four segments
transmitted after the lost one are successfully delivered so that a total number of 3 du-
plicated ACKs are generated. In the SM, the state
situations are represented by states
?is the small-size segment loss probability.
?represents this case. Similar
We denote by
?the transition probability from state
?, we have,
Since in state
accounts for the probability that at least 3 segments following the lost one are correctly
received, so that FR can be triggered.
Once the FR is completed, the SM will always move to the state labeled 8, where
8 small segments are sent. This is due to the clipping of the Slow Start threshold to
?the number of segments which follow the lost one is
???, the sum
The transition from state 4 to state 8 represents the case in which all the four seg-
ments transmitted when window size is equal to 4 are successfully delivered so that,
after roughly a round-triptime, the window size is equal to 8 small segments. The tran-
sition probability is equal to
When some losses occur and FR can not be entered, the SM moves from state 4 to
??; the probability of this transition is,
The SM can then leave the state
larly to what happens from state 4, the SM can move to a state
ACKs arrive, or remain in the state
When the window size is 8, the probability that RTO is used instead of FR is ex-
tremely small, therefore, we assume that in case of losses FR only is possible. Loss
occurrence and recovery when the window size equal to 8 is represented by the transi-
tion from state 8 to itself; the transition probability is equal to
that the window size does not change due to the minimum Slow Start threshold which
is equal to
Similarly to (2) in previous model, the throughput is evaluated as the ratio of the
average number of transmitted segments,
In orderto evaluate
each visit to a state is weighted by the time spent in that state. The time spent in state
4 is equal to RTT. The time to recover a loss in
?? and move to state
? if no loss occurs, or, simi-
?, if three duplicate
?, over the time spent by TCP-SF in the
?, all the paths from state 4 to 16 are considered;along a path,
?is RTT, while in states
which enlarge the window and allow the transmission of new segments; one more RTT
is needed to receive the ACKs of these new segments. The time spent in
the average timeout
The average number of transmitted segments,
all the possible paths; along a path each visit to a state is weighted by the number of
segments transmitted in that state. We associate four segment transmissions to states 4
Thus, 0 segments are transmitted in
??, two round trip times are needed. Indeed, one RTT is needed to receive the ACKs
?? is equal to
?, which is computed by substituting
? in (1).
?, can be derived again considering
??, so that states
?account for transmissions due to window enlargementonly.
?, 2, 4, and 6 are respectively transmitted in
?. Eight segment transmissions are associated to state
0 0.02 0.04 0.06 0.08
Segment loss probability
Throughput gain [%]
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
Round trip time [s]
Throughput gain [%]
Fig.3. Throughput gain in the small window region for TCP-SF over Classic TCP versus the
full-size segment loss probability (on the left) and versus round trip time (on the right).
For the sake of brevity we do not report here the formula for the
throughput is given by, where
??is equal to 4 in the considered case.
Loss probability has a remarkable impact on the achievable performance gain. In order
to estimate the performance gain we need to evaluate the ratio
full-size segment loss probability,
that the gain achieved by TCP-SF grows with
Since the segment loss probability depends on network congestion, on buffer man-
agement policies at routers and on the segment size, it is in general difficult to estimate
?, and the small-size segment one,
?. We expect
?. Therefore,instead of setting a scenario and deriving
ferent values of
When RED buffer management schemes are adopted, the queue length is managed
in bytes, thus it is reasonable to assume that the segment loss probabilityis proportional
to the segment size, as suggested in . Then, the probability to lose a small segment,
? accordingly,we considerdif-
? which are representative of a wide set of cases. As limiting cases we
???. The rationale behind this choice is illustrated below.
equal to 4. On the contrary, as a worst case, we consider a buffer management scheme
which handles packets as units, independently of their size. In this case,
?, is about 4 times smaller than the probability of losing a full-size segment
?is equal to
Left plot of Figure 3 shows the throughput gain of TCP-SF over Classic TCP in
the small window regime versus the full-size segment loss probability and for different
chosen values of segment loss probabilitywere taken from simulation results for differ-
ent values of offeredload,see Section4.Points in the plot are computedin the following
way. Given a value of the segment loss probability
?. The average round trip time is equal to 200 ms, RTO is set to 1.5 s. The
?, we first compute the probability
? ??. Then, we obtain the throughput of TCP-SF and of Classic TCP from the
models as in (2) and in (3). We compute the throughputgain
As expected, the throughput gain increases with the segment loss probability and with
the loss probability ratio
than double the throughput of Classic TCP.
Since the advantage of TCP-SF is mainly due to the smaller time spent in FR rather
than waiting for RTO expiration, we now focus on the impact of the values of RTT
and RTO on the throughput gain. In the right plot of Figure 3 the throughput gain is
plotted versus RTT for different values of RTO. The full-size segment loss probability
?. In the small window region, TCP-SF achieves up to more
? is set to 0.1; small segments are lost with probability
RTO, as the round trip time increases the difference between RTO and RTT decreases;
consistently, the throughput gain decreases. Notice however, that for the considered
scenario, the throughput gain is remarkable also for the minimum admissible value of
????. Given a value of
RTO, i.e., RTO ?
only. Short-lived flows benefit of further advantages in using TCP-SF which are not
considered in this analysis, such as, for example, the higher chance not to use the initial
RTO. For longer flows, on the contrary, the benefits of adopting the smart framing
option are observed only at the connection set up and when Slow Start is entered due to
4 Performance Evaluation
We have chosen to investigate the performance of TCP-SF using both simulation and
actual testbed measurements. Simulation gave us full control over specific scenarios.
On the other hand, the testbed implementation allowed a more realistic evaluation fea-
turing actual traffic patterns. Specifically, our approach splits the measurements into
two stress tests: real network, synthetic traffic: these tests were performedusing a client
and a server on remote systems, respectively requesting and sending pools of data over
the Internet; such tests allowed us to control the amount of traffic injected into the net-
work, and, in general, to have greater control on the type of results we wish to obtain;
real traffic, synthetic network: tests using real traffic involved a proxy server on a de-
partmental subnet fed through a link emulator; these tests gave us control on such key
network parameters as packet loss and latency, while the traffic reflected actual usage
patterns, as will be detailed below.
We implemented both flavors of TCP-SF in the ns-2 simulator . For our testbed
measurements, we implemented the Fixed-Size version in the Linux kernel 2.2.17.
4.1 Simulation results
We report results for network scenario in which both long-lived FTP-file transfer and
Web-like connectionssharea commonbottlenecklink.In particularwe derivedtheflow
lengthdistributionreportedinthesecondcolumnoftable1 fromthe AT&TLabs’traffic
estimate .The distributionwas obtainedby dividingtheflows in 10 identicalgroups
and computing the average flow length for each group. As can be seen, more than 70%
0.10.20.30.4 0.50.6 0.70.8 0.91
Bottleneck Offered Load
Fig.4. Average completion time: Comparison between TCP-SF and normal TCP (SACK en-
of the flows are shorter than 11 Kbytes, and thus FR can not be triggered if the MSS is
1.5 Kbytes, as the most common used today.
To model Web-like traffic, TCP-SACK traffic generators are connected to a bottle-
neck link of 10 Mbit/s capacity and 50 ms delay. A Poisson process drives the setup
of new connections, whose length (in bytes) is randomly set according to the previ-
ous traffic distribution. The
accounted for using 10 greedy TCP sources. The bottleneck link is managed by a byte-
wise Droptail buffer, whose capacity is set to 150 Kbytes. To get rid of transient effects,
the simulation time is 4,000 seconds.
Figure 4 plots the average Completion Time, i.e., the time that is required by the
source to successfully transfer all the data, for the classic TCP-SACK implementation,
and for the proposed VS- and FS-TCP-SF, versus the average offered load normalized
with respect to the bottleneck capacity. As expected, the average completion time re-
quired to end the transfer is larger when the offered load grows. This is due to two
main reasons: first, the average window size shrinks as the capacity of the link is shared
among a largernumberof flows. Second, the probabilityof segment loss is larger,caus-
ing either RTO or FR to occur.
On the contrary, both VS- and FS-TCP-SF outperform Classic TCP, as they are
quicker to react to segment losses. In particular, when the offered load is smaller than
When, instead, the offered load is larger than 0.9, the probability of multiple drops per
RTT increases, and thus VS-TCP-SF is no longer able to avoid RTO. On the contrary
FS-TCP-SF shows the best performance. To give further insight about the performance
that both flavors of TCP-SF are able to obtain, Table 1 reports, for different flow group,
the average completion time, the percentage of FR and RTO instances used to detect
segment loss for Classic TCP, VS- and FS-TCP-SF. The offered load was fixed and
equal to 0.8. It should be noted that, for some flow lengths, FR is not observed since
there are not enough segments to trigger it.
As can be seen, both flavors of TCP-SF outperformthe Classic TCP performancein
terms of completion time for all flow lengths. Specifically, different completion times
are observed, even if the RTO and FR percentage are the same, because each scenario
??? is set to 1,460 bytes. Long-lived connections are
Table 1. Average Completion Time (CT) and Percentage of FR and RTO occurrences per group.
Group bytes ClassicVS-TCP-SF FS-TCP-SF
CT % FR % RTO CT % FR % RTO CT % FR % RTO
0.25– 100.00 0.22–
– 100.00 0.28
– 100.00 0.34
– 100.00 0.42 8.02
– 100.00 0.53 33.52 66.48 0.64 35.57 64.43
–100.00 0.54 43.26 56.74 0.86 32.00 68.00
– 100.00 0.77 52.12 47.88 0.93 30.02 69.98
10910 1.96 5.54
94.46 1.00 64.78 35.22 1.16 37.26 62.74
18978 2.17 21.91 78.09 1.23 62.98 37.02 1.57 49.01 50.99
90439 4.43 46.34 53.66 3.01 69.68 30.32 3.87 64.64 35.36
61 100.00 0.24
91.98 0.49 10.84 89.16
exhibits a slightly different loss probability. For example, although all group-0 flows
do not benefit from the TCP-SF enhancement, their completion times differ because
dropping probabilities for TCP-SF were slightly smaller.
In particular, Table 1 underlines the benefits obtained by TCP-SF in increasing the
number of FR, while at the same time reducing the RTO occurrences. The benefits are
clearly visible starting from flows that have to send 1,349 bytes (group 3): using TCP-
SF, they manage to trigger the FR algorithm. On the contrary, the first class of flows
that can use FR for the Classic TCP is the one that has to send 10,910 bytes (group 7),
where only less than 6% of dropped segments trigger FR. This is reflected by a smaller
completion time required to successfully end the transfer (i.e., reduced by half).
A counterintuitive result is observed for connections belonging to classes 5 and
higher: the VS flavor appears to run into FR more frequently than FS-TCP-SF, even
though FS sends more small-size segments (thus increasing the chance to trigger FR).
However,the burstiertraffic generatedby FS-TCP-SF causes multipledropsthat cannot
be recovered but through RTO.
4.2 Testbed measurements: real network, synthetic traffic
To gauge the impact of our new scheme in a real Internet environment, we have imple-
mented FS-TCP-SF on a Linux workstation acting as file server. We have then tested
the implementation using several clients (adopting different OSs) which requested 10-
Kbytes file uploads to the server, the clients being located both on the local network (in
Italy) and in the Internet at large (in the U.S.A.). Each client repeated the requests some
20,000 times over a time span of 4 hours during peak business hours in Italy.
Results in Table 2 are reported in terms of FR and RTO occurrences, similarly to
Italy-to-U.S.A. path is usually lightly loaded, most of the traffic flowing in the opposite
direction. Thus, a small fraction of the flows suffered from segment losses. This is
reflected in a average completion time measure that is almost constant, and we opted
not to report it. On the contrary, the frequency of FR and RTO occurrences are a more
significant metric because they are a relative measure.
Table 2. Percentage of FR and RTO occurrences measured per host.
% FR % RTO % FR % RTO
On the whole, the testbed results confirm what we observed in simulation: TCP-
SF connections resort to FR four times more frequently than Classic TCP does. This
behavior, in presence of a larger percentage of drops, would have lead to a significantly
smaller completion time, as shown by simulations.
4.3 Testbed measurements: real traffic, synthetic network
The second set of testbed experiments involved a realistic traffic pattern (i.e., Web
client-server transactions) routed over a link emulator. The topology of the testbed is
described in Figure 5. Its functional elements are the following:
– a switched 100 Mb/s LAN carrying Department traffic;
– a Web Proxy Server used by clients on the Department Subnet;
– a Router
over a 32 Mb/s link;
– a Router
affecting only traffic from the Proxy Server;
– all links except for the outgoing ones are Full Duplex Fast-Ethernet.
? connecting to the Internet and carrying outbound and inbound traffic
?implemented on a Linux machine which also runs a Link Emulator,
In order to generate realistic traffic, every Web browser in our Department Subnet was
configured so as to use the Proxy Server. TCP-SF was only implemented over the ma-
chine running the Proxy Server, and a link emulator was added on the return path be-
tween the Proxy and the Department Subnet. The link emulator was configured so as
to enforce a specific latency and byte-wise drop probability (i.e., longer packets have
a higher probability of being dropped than smaller ones). The above configuration al-
lows a substantial amount of traffic (namely, the Web objects fetched by the Proxy and
returned to the requesting clients on the Department Subnet) to be sent over the link
emulator using TCP-SF as transport layer.
Performance metrics were collected for different values of emulated latency and
drop probability, over a period of one month in June 2001; in order to collect a mean-
ingful set of data, each latency/drop pair was set for a whole day, and the Proxy Server
had its transport layer switched between Classic TCP and TCP-SF every five minutes.
were later collected for each version of TCP, and for each day. Unlike the results in the
previous Subsection, we had little control over the actual client sessions: the amount of
system installed on each user’s machine. Also, each browser has its own session-level
behavior, including idle time between back-to-back requests, or connection shut-down
Fig.5. Topological description of the Real Traffic-Synthetic Network experiment.
after a timeout. Unfortunately, this prevented us from obtaining reliable estimates of
completion times. Indeed, completion times are computed at the Proxy Server as the
time elapsed between the reception of a SYN segment from a client, until the last FIN
(or RST) segment is received by the server, or sent by the server, whichever occurred
last. Flows that did not transport any payload are not taken into account. We have thus
chosen to report just the difference between the completion times of TCP-SF and Clas-
sic TCP, assuming that, on the whole, whatever discrepancies between the behaviors of
different clients’ OSs and browsers would equally affect the two versions of TCP being
switched on the Proxy Server. We are aware that these statistics are hardly reliable, but
we chose toreportthemanyway,since theymightgivean indicationas to whichversion
ensures a faster completion.
Also, the percentages of Timeout expiration are reported, as in Subsection 4.2. Un-
like completion times, statistics on the occurrence of RTOs and triple duplicate ACKs
are less depended on browser behavior, and are therefore a more reliable metric. These
results are shown in Tables 3, 4 and 5, each Table referring to a result set collected by
file size (smaller than 10 kB, between 10 and 100 kB, and larger than 100 kB).
ber (number of flows); estimate of the average Retransmission Timer per connection;
percentage of times a loss resulted in an RTO expiration instead of triggering Fast Re-
covery;completiontime differencebetween the two examinedTCP versions,computed
only for flows that have experienced at least one loss event.
Observe that positive values for the completion time difference indicate that TCP-
SFexhibited a faster completion time, while negative times indicate the opposite.
First of all, it should be observed that the number of samples is significantly larger
for flows smaller than 10 kB, confirming that a majority of the Internet traffic today is
made up of short-lived flows. Also, we remark that the number of samples allows some
confidence in the statistical examination of the output only for file sizes smaller than
100 kB. Statistics regarding larger file sizes are reported here for completeness.
Overall, results confirm the findings shown in previousSections via simulation and,
specifically, identify TCP-SFas less prone to RTO expirations than Classic TCP. Esti-
mating the proper value of the Retrasmission Timer also benefits from the features of
TCP-SF: the larger number of segments sent, compared to Classic TCP, accounts for a
larger number of samples used in the estimation, thus refining the estimate and provid-
ing a smaller, more accurate value for the timer. The combined effects of fewer RTOs
Table 3. Percentage of RTO occurrences, RTO estimates and completion times for web objects
smaller than 10 kB as a function of the emulated drop probability and latency.
drop latency Classic TCPTCP-SF
probability [ms] Samples RT [ms] % RTO Samples RT [ms] % RTO
0.0120 8093 435
and smaller values of the retransmission timer shortens the completiontime in presence
of a loss
predictablebehaviorofdifferentbrowsertypes, the trend nonethelessconfirmsa sizable
reduction of completion times for TCP-SF.
????; although we remarked that completion times are affected by the un-
Table 4. Percentage of RTO occurrences, RTO estimates and completion times for web objects
sized between 10 kB and 100 kB, as a function of the emulated drop probability and latency.
droplatency Classic TCPTCP-SF
probability [ms] Samples RT [ms] % RTO Samples RT [ms] % RTO
We proposedan enhancementto the TCP protocolthat is based on the key idea of trans-
mitting smaller size segments when the congestion window is smaller than
without changing the degree of aggressiveness of the source. This allows the sender
to receive more feedback from the destination, and thus use the Fast Recovery algo-
rithm to recover from segment losses, without waiting for a Retransmission Timeout
expiration to occur. TCP-SF is particularly effective for short-lived flows, but improves
the responsiveness of long file transfers also. Coupled with the current Internet traffic,
Table 5. Percentage of RTO occurrences, RTO estimates and completion times for web objects
larger than 100 kB, as a function of the emulated drop probability and latency.
drop latencyClassic TCPTCP-SF
probability [ms] Samples RT [ms] % RTO Samples RT [ms] % RTO
0.0120 139 253
TCP-SF outperforms Classic TCP in terms of both completion time, and probability to
trigger Fast Recovery to detect segment losses.
The proposed modification is extremely simple and can be implemented on the top
of any TCP flavor, and requires changes on the server side only.
Hands-on measurements of Internet traffic could not have been possible without the
cooperation of several people from our Department who willingly (or unaware), left
their browsers at our mercy for a month or so. In acknowledging their help, we also
wish to thank the Politecnico di Torino Network Facilities (CESIT) that allowed us to
take the network measurements, and Mario Gerla at UCLA and the Computer Science
Facility at CMU for letting us run remote experiments on their workstations.
1. S. Floyd. A Report on Recent Developments in TCP Congestion Control. IEEE Communi-
cations Magazine, April 2001, pp 84-90
2. M. Allman, V. Paxson, W. Stevens. TCP Congestion Control. RFC-2581, April 1999
3. V. Jacobson, “Congestion Avoidance and Control”, Sigcomm 88, Standford, CA, pp. 314-
329, Aug. 1988
4. S. Floyd, T. Henderson, “The NewReno Modification to TCP’s Fast Recovery Algorithm”,
RFC 2582, Apr. 1999
5. M. Mathis, J. Mahdavi, S. Floyd, S., A. Romanow, “TCP Selective Acknowledgment Op-
tions”, RFC 2018, Apr. 1996
6. ns-2, network simulator (ver.2). http://www.isi.edu/nsnam/ns/
7. S. De Cnodder, O Elloumi and K Pauwels. RED Behavior with Different Packet Sizes.
Proceedings of the Fifth IEEE Symposium on Computers and Communications (ISCC 2000)
8. W.R. Stevens. TCP/IP Illustrated, vol. 1. Addison Wesley, Reading, MA, USA, 1994.
9. D. Clark. Window and Acknowledgment Strategy in TCP. RFC-813, July 1982.
10. A. Feldmann, J. Rexford, R, Caceres. Efficient policies for carrying Web traffic over flow-
switched networks. IEEE/ACM Transactions on Networking, Vol: 6, NO: 6, Dec. 1998