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
1Introduction 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).
2TCP 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-
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