<?xml version="1.0" encoding="utf-8" standalone="yes"?><html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>TCP throughput constraints</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta content="text/css" http-equiv="Content-Style-Type" />
<script src="NED?action=retrieve&amp;identifier=dn00188761&amp;edition=1&amp;language=none&amp;coverage=global&amp;encoding=javascript&amp;component=data&amp;item=data" type="text/javascript" xml:space="preserve">
</script>
<?conversion name="Pub2XHTML" version="2.0" source="urn:mars:dn03301829:4:en:global:publishing_online_1_0:data:data:*:*:*" date="2005-02-21T13:15:50Z"?>
<link href="NED?action=retrieve&amp;identifier=dn01158124&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=css&amp;component=data&amp;item=data" rel="stylesheet" title="Nokia Networks default online style" type="text/css" />
<meta content="draft" name="status" />
<?conversion name="SplitHTML" version="1.9" source="urn:mars:dn03301829:4:en:global:publishing_online_1_0:data:data:48:*:*" date="2005-02-21T13:15:50Z"?>
</head>
<body lang="en" xml:lang="en">
<p><a name="nov194152663" shape="rect"></a>
<a name="ned_3" shape="rect"></a></p>

<div class="div">
<div class="div">
<table width="100%">
<tr>
<td align="center" colspan="1" rowspan="1" width="20%"><?NED5 annotation?>
<br clear="none" /><?NED5 printview?>
</td>
<td align="center" colspan="1" rowspan="1" width="20%"></td>
<td align="center" colspan="1" rowspan="1" width="20%"></td>
<td align="center" colspan="1" rowspan="1" width="20%"><a href="NED?action=retrieve&amp;identifier=dn03301829&amp;edition=4&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=ned_2#ned_2" onclick="sync(this);return true" shape="rect">TCP/IP and throughput optimisation for EGPRS</a></td>
<td align="center" colspan="1" rowspan="1" width="20%"><a href="NED?action=retrieve&amp;identifier=dn03301829_about&amp;edition=4&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=ned_top#ned_top" onclick="openSmallPopup(event,'NED?action=retrieve&amp;identifier=dn03301829_about&amp;edition=4&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=ned_top#ned_top');return false" shape="rect" target="_blank"><img alt="Document information" border="0" class="Metainfo" src="NED?action=retrieve&amp;identifier=dn01158003&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=gif&amp;component=data&amp;item=data" /></a></td>
</tr>
</table>


<div class="div">
<h3>TCP throughput constraints</h3>

<a name="feb2231737363" shape="rect"></a>
<div class="topic">
<h4>Absolute
throughput boundary for infinite link bandwidth</h4>

<p>The absolute throughput boundary of the TCP protocol can
be estimated using the following equation, which is also illustrated in Figure <em>Upper throughput boundary of TCP</em>. The main contributors
to TCP performance are:</p>


<ul>
<li><p>Round Trip Time (RTT)</p>
</li>
<li><p>packet loss</p>
</li>
<li><p>available link bandwidth.</p>
</li>
</ul>


<a name="mar63174471" shape="rect"></a>
<div>
<img alt="urn:mars:dn03316889:1:en:global:cgm_fixed:data:data" border="0" src="NED?action=retrieve&amp;identifier=dn03316889&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=gif&amp;component=data&amp;item=data" /></div>


<a name="mar6317642" shape="rect"></a>
<div>
<img alt="urn:mars:dn03316892:1:en:global:cgm_fixed:data:data" border="0" src="NED?action=retrieve&amp;identifier=dn03316892&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=gif&amp;component=data&amp;item=data" /><p class="figure-caption">Figure: Upper throughput boundary of TCP</p>
</div>
</div>


<a name="feb223174054" shape="rect"></a>
<div class="topic">
<h4>Size
of TCP Receiver Window (RWND)</h4>

<p>A large TCP window size is needed due to the large bandwidth-delay
product (BDP). The TCP receiver has to advertise a large window size to the
sender. In addition, the TCP transmitter must be set up with a large congestion
window size. The receiver determines an upper limit for the congestion window
(CWND) so that it is equal to or lower than the value indicated by the receiver.
A heavily overdimensioned TCP receiving window size can lead to poor performance
in situations where some of the TCP packets are dropped.</p>


<p>The maximum TCP throughput is limited by the size of the
TCP receiver window (RWND) according to the following equation:</p>


<a name="mar6317763" shape="rect"></a>
<div>
<img alt="urn:mars:dn03316923:1:en:global:cgm_fixed:data:data" border="0" src="NED?action=retrieve&amp;identifier=dn03316923&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=gif&amp;component=data&amp;item=data" /></div>


<p>The following formula can be used to estimate the optimal
RWND: it should be greater than the BDP value and at the same time an exact
multiple of the Maximum Segment Size (MSS).</p>


<p>BDP = bandwith (in the radio channel) * delay (RTT), where</p>


<p>bandwith (in the radio channel) = number of TSLs * bits
(depending on CS used)</p>
</div>


<a name="feb2231742576" shape="rect"></a>
<div class="topic">
<h4>Slow
start and Congestion Control of TCP</h4>

<p>The TCP considers packet loss an indication of network
congestion. Network congestion is managed using Slow Start and Congestion
Avoidance algorithms, which are not optimised for mobile networks such as
EGPRS. </p>


<p>In Slow Start the sender increases the congestion window
exponentially after each acknowledgement received from the receiver. The congestion
window can be enhanced up to the window size advertised by the receiver.</p>


<p>When congestion takes place, a method is needed to slow
down the transmission rate. The Congestion Avoidance algorithm is the standardized
method. The algorithm is executed when several packets are lost and timeout
occurs. The term “critical window” is used here to refer to the window size
during timeout. </p>


<p>After a timeout the window is dropped down to the initial value of CWND
and the Slow Start procedure is started. Congestion Avoidance starts when
the window has again grown to half of the critical window size. After that
the window is increased by one segment for each RTT: the window grows in a
linear fashion, not exponentially as in Slow Start [RFC2581]. Note that Congestion
Avoidance is used always with Slow Start when a timeout occurs: TCP will slow
down the transmission speed even if the packet loss happened because of data
corruption. This can result in poor link utilization especially in a wireless
environment where bit error rates are high and timeouts are not always a result
of congestion.</p>


<p>The detailed operation depends on TCP performance optimisation
options. </p>


<a name="mar631712381" shape="rect"></a>
<div>
<img alt="urn:mars:dn03316959:1:en:global:cgm_fixed:data:data" border="0" src="NED?action=retrieve&amp;identifier=dn03316959&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=gif&amp;component=data&amp;item=data" /></div>
</div>


<a name="feb2231744587" shape="rect"></a>
<div class="topic">
<h4>Maximum
Transmission Unit (MTU) and Maximum Segment Size (MSS)</h4>

<p>It is recommend to use a large TCP segment size (MSS =
1460 B, MTU = 1500 B) with EGPRS. The larger the segment size, the more quickly
the TCP transmitter can fill the transport path with data during the Slow
Start procedure.</p>


<p>The TCP receiver advertises the segment size it supports
in the SYN message. The TCP transmitter then determines the segment size so
that it is equal to or smaller than the value indicated by the receiver.</p>
</div>


<a name="feb2231745238" shape="rect"></a>
<div class="topic">
<h4>Windows
Scaling (RFC1323)</h4>

<p>Windows Scaling enables window sizes larger than 64 kB.
This option is not recommended because a 64 kB window is sufficient for EGPRS.</p>
</div>


<a name="feb2231745509" shape="rect"></a>
<div class="topic">
<h4>SACK
(RFC 2018)</h4>

<p><a href="NED?action=retrieve&amp;identifier=general_glossary&amp;edition=13&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=id011320#id011320" onclick="openSmallPopup(event,'NED?action=retrieve&amp;identifier=general_glossary&amp;edition=13&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=id011320#id011320');return false" shape="rect" target="_blank">SACK</a> option is recommended because
it improves the TCP error recovery when multiple packets per window are lost.
SACK option is enabled only if both TCP peers support it.</p>


<p>Some typical use cases where multiple packets may be lost
are Cell Change or network congestion.</p>
</div>


<a name="feb2231746610" shape="rect"></a>
<div class="topic">
<h4>Initial
TCP Window</h4>

<p>It is recommended to have a large initial TCP congestion
window size in order to speed up the Slow Start procedure in the beginning
of a data transfer or in case of recovery after the RTO expires because of
congestion, for instance.</p>


<p>Initial TCP congestion window size is the parameter of
the TCP transmitter.</p>
</div>


<a name="feb22317464211" shape="rect"></a>
<div class="topic">
<h4>Delayed
ACK</h4>

<p>To ensure faster incrementing of the congestion window,
the TCP receiver should not delay the TCP ACKs during the Slow Start phase.</p>


<p>TCP ACKs are typically delayed by 200 ms. Note that each
TCP segment will be acknowledged by a separate TCP ACK if the following equation
holds:</p>


<a name="mar631715492" shape="rect"></a>
<div>
<img alt="urn:mars:dn03316974:1:en:global:cgm_fixed:data:data" border="0" src="NED?action=retrieve&amp;identifier=dn03316974&amp;edition=1&amp;language=en&amp;coverage=global&amp;encoding=gif&amp;component=data&amp;item=data" /></div>
</div>


<a name="feb2231813421" shape="rect"></a>
<div class="topic">
<h4>TCP
Time Stamps (RFC 1323)</h4>

<p>TCP time stamp option improves the TCP sender’s capability
to measure the round-trip time (RTT), on the basis of which the retransmission
timer is adjusted. Consequently, this option might improve the performance
when RTT variation is high, as in the case of simultaneous uplink and downlink
data transfer. Note that this option increases the TCP/IP header by 12 bytes,
which is almost negligible for MTU=1500. The timestamp option is recommended
for EGPRS.</p>
</div>


<a name="feb223181452" shape="rect"></a>
<div class="topic">
<h4>NewReno </h4>

<p>The use of NewReno RFC 2582 is not recommended.</p>
</div>


<a name="feb2231814193" shape="rect"></a>
<div class="topic">
<h4>Computing
the retransmission timeout (RTO) (RFC2988)</h4>

<p>RFC2988 suggests that when an ACK is received that acknowledges
new data, the retransmission timer restarts so that it will expire after <a href="NED?action=retrieve&amp;identifier=general_glossary&amp;edition=13&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=id013459#id013459" onclick="openSmallPopup(event,'NED?action=retrieve&amp;identifier=general_glossary&amp;edition=13&amp;language=en&amp;coverage=global&amp;encoding=xhtml_1_0&amp;component=data&amp;item=data&amp;pointer=id013459#id013459');return false" shape="rect" target="_blank">RTO</a> seconds (the current value of RTO).</p>


<p>This helps manage the increase in RTT due to filling of
buffers during the Slow Start procedure.</p>
</div>


<a name="feb2231814384" shape="rect"></a>
<div class="topic">
<h4>Explicit
Congestion Notification RFC2757</h4>

<p>RFC2757 recommends the implementation of Explicit Congestion
Notification (ECN) for Long Thin Networks (LTNs). Note, however, that EGRRS
cannot be considered an LTN and therefore ECN is not recommended. Support
from Proxy or router network is needed.</p>
</div>
</div>
</div>
</div>
</body>
</html>