The present and the future of TCP/IP

David Espina

Dariusz Baha

Project in Electronics

Computer science

dea09001@student.mdh.com

dba04002@student.mdh.se

ABSTRACT
The Transport Control Protocol (TCP) and Internet
Protocol (IP) are the two most important communication
protocols used in computer network today. In this paper we
describe the evolution and the basic functionality of the
TCP\IP protocol. After reading this article the reader will
have a brief knowledge of the origin and evolution of TCP
and IP, as well as their structure, operational lifetime and
philosophy. We expose the reasons why the first
information networks needed to evolve to become what we
know nowadays as the internet. Finally a future view is
detailed of what the recent studies and tested technologies
bring as the best solution to support the growing demands
of the users and technological improvements. Multi-bit
control feedback, are the key words to describe the future
in network communications. Technologies like FAST TCP,
delay-based systems and the 4G Mobile Networks based on
IP are the most modern researches and the future for all
networks communication.

1. INTRODUCTION
The TCP protocol belongs to the Transport Layer in the
OSI model which is an abstraction model for computer
communication through networks. The task of the TCP
protocol is to ensure a reliable communication between two
hosts on an unreliable network. In one end it provides a
service to the communicating application and in the other
end, the IP protocol.
In section II the birth of the protocols is explained both
sociological and technological purposes. Since the 1960s
the military in collaboration with several different
universities in the U.S. started working in the
implementation of a global network which purpose was
connecting different locations working under different
protocols and share information with several kinds of
storage systems.
In Section III we explain some basic functionalities of the
TCP protocol and how it works. We will concentrate on
connection establishment, connection release and the
sliding window protocol.
An expert reader may be interested in skipping the whole
previous sections to section IV where is explained in detail
the most recent discoveries and implementation about TCP
page 1 of 8

and IP. There, some specifications about FAST TCP are

detailed; a new estimation about the flux in the network is
approached by the concept of delay-based systems instead
of packet loss rate.
Section V contains the conclusions reached after
discussions about the statements in section IV always
minding the history and evolution of the protocols.

2. History of TCP/IP
IP was born to cover U.S. Department of Defenses
communication needs. Last years of the 1960s the
Advanced Research Projects Agency (ARPA), which is
known nowadays as DARPA, started developing in
common with some partner universities and the corporate
research community the design of standard protocols and
started building first multi-vendors networks. The result of
working all together was ARPANET, the first packet
switching network that was tested in 1969 with four nodes
using Network Control Protocol. After the successful test
the new born network turned into an operational network
called ARPA Internet. In 1974 Vinton G.Cerf and Robert
E.Kahn designed TCP/IP protocols.
In January 1980 the Institute of Information Sciences at
University of Southern California elaborated a reference
document [5] describing the philosophy of the Internet
Protocol. It was designed to be used in an environment of
computer communication networks oriented to packet
switched systems interconnected between them.
In 1985 ARPANET started suffering from congestion and
the National Science Foundations developed NSFNET to
support the previous net which was finally closed in 1989.
The NSFNET was based on multiple regional networks and
peer networks such as NASA Science Network. By 1986
there was a network architecture connecting campuses and
research organizations connected also to super computer
facilities. Over the years the speed of transmissions had to
be increased and by 1991 the backbone was moved to a
private company which started charging for connections
and companies like IBM developed ANSNET in parallel
which was nor aimed to enrich these companies.
The structure of the information running through the
network was designed as blocks of data split in small

segments of bits called datagrams. Datagrams are

packaged and sent from sources to destinations which are
both hosts distinguished by a fixed length address. These
datagrams are long enough to be considered a risk of loss
of information due to the characteristics of the
communications channel, fragmentation and reassembly.
The internet protocol covered all needs to provide host-tohost delivery and its limitation such as reliability, flow
control, sequencing among others, were not considered.
The internet protocol was meant to interact with local
network protocols to transport the required datagram to the
next gateway or destination host. It implemented
addressing and fragmentation as two basic functions. The
datagram contains information about host source and host
destination within its header. This information is coded as
an address and in order to complete the delivery a path
must be chosen. The operational structure isolates every
host and its gateway that connects to the global network.
These isolated modules take decisions based on common
rules to interpret datagrams and make routing decisions as
well as other functions. Each datagram is treated as an
independent unit on its way through the network. Any trace
of logical circuits or connections is banished.
To provide service, four parameters were created: Type of
Service, Time to Live, Options and Header Checksum. The
first one provides information about the QoS (Quality of
Service) available being eligible for example Real Time,
Interactive or Bulk. This QoS responds to how gateways
manage the transmission parameters for a specific network,
the network used by the next node or the next gateway
when routing a datagram. Time to Live is a countdown
number that indicates how long a datagram is meant to last
and after reaching zero it is self destroyed. Options
parameter does not represent a vital part of the protocol
because gives support to non regular situations in the
communications process when errors occur or special
routing is needed among others. The fourth parameter
created was Header Checksum which gives feedback
information about the correct transmission. If this
parameter shows an error the whole datagram is discarded
and a fundamental characteristic that comes with this error
assumption is that IP does not have retransmissions, error
control for data but the header checksum or flow control.
As computer communication became more and more
important, especially for the military at that time. It was
realized that a robust communication standard is needed to
replace the variety of different local network protocols that
were used. A concept for the TCP was first described in [8]
where several issues that would be solved where presented.
The TCP was declared to be a reliable connection-oriented,
end-to-end protocol. It was meant to operate on top of the
IP protocol. TCP was first defined in [4].

page 2 of 8

3. Present TCP/IP
To accomplish its task, both the receiver and the sender
must create communication end points, called sockets, or
more precisely the communicating processes on each of the
senders and receivers machines are creating the sockets. It
is trough the sockets that the communicating processes can
send and receive data. Each socket has an IP address and a
port number. There are some well known port numbers like
port 21 for the FTP protocol which with many others is
included in the TCP/IP suite. Port numbers below 1024 are
reserved for such well known services. A TCP connection
is established between two hosts only, which mean that
multicasting and broadcasting is not supported. Some
features of the TCP include buffering of data, which means
that the data passed to TCP may not be sent immediately
instead the TCP may buffer it. Hence a larger chunk of data
can be sent. This means that the data is sent as a byte
stream and not as a message stream.

3.1 The TCP Segment Structure

The TCP uses a segment structure to send data. Each
segment contains information for the TCP/IP protocol, as
well as the data itself. First we have the IP header with a
fixed size of 20 bytes. The IP header contains IP specific
information, like the IP address. After the IP header we
have the TCP header, also with a fixed size of 20 bytes.
Attached to the end of the TCP header is the data itself, the
size of the data can be 0 65,495 bytes [7].

Figure 3.1 TCP header. [7]

First we have the source and destination port fields, these
are for the 16-bit port numbers that identify the sending and
receiving applications. Sequence numbers are used to
ensure that packets arrive in the right order, no packets are
missing and to detect duplicates. We will explain this
further in the following section. Acknowledgments are used
to ensure that packets have arrived at their destination. The
TCP header length field basically shows where the data
field begins. This is because the options field is variable.
After the reserved space, there are six 1-bit fields for
different flags.

TCP is using a flow control protocol called sliding window.

The window size field specifies the number of bytes that
may be sent to the receiver. The window size may change
trough out the lifetime of a connection. A value of zero
means that the receiver doesnt wish to receive more data.
This is useful if the receiver becomes overloaded. In the
checksum field, a checksum of the whole header including
the data is calculated. The urgent data pointer is for the
signaling mechanism in the TCP protocol, this field
indicates the last byte of the urgent data. The options field
is variable and allows adding extra functionality to the
header.

3.2 TCP Operation

A TCP connection undergoes three main stages throughout
its lifetime. First a connection must be established, this is
the connection establishment phase. Secondly the
connection enters the establishment phase, it is in this phase
that data is sent and received. And last the connection
release phase where the connection is terminated and all
resources are released.

3.2.1 Connection Establishment

For two hosts to be able to communicate, they first need to
establish a connection. There are some problems that need
to be handled in order for a safe connection to be
established. One such problem is the fact that the
connecting host, sending a connection request message to
another host cannot know if the connection request was
received or not, as we know the internetwork is not reliable
and packets can be lost or reappear after some time, these
are called duplicates which is the second concern that has
to be handled. How can the receiving host know that the
connection request is actually a request and not an old
duplicate. To solve these problems the TCP protocol is
using a method called the three-way handshake [7], the
basic idea is that the sending host sends a synchronization
(SYN) package to the receiving host. The receiving host
responds by sending back his own SYN packet together
with an acknowledgement (ACK), forming an SYN-ACK.
This is to show to the sending host that it has received the
SYN. Lastly the sending host responds with an ACK.
Totally three packets have been transmitted between the
sending and receiving host, hence the name three-way
handshake. The whole process is illustrated in Figure 3.2.

Figure 3.2 Three-way handshake. [7]

What is important to note is the content of the SYN and
ACK packages. The SYN packet is basically a TCP header
containing no data, with the SYN flag set and a sequence
number, x. The sequence number is a randomly chosen 32bit value. When Host 2 replies it also chooses its own
randomly chosen sequence number, y and also in the
Acknowledgement number field Host 2 sets an
acknowledgement number which is the sequence number
from the SYN message of Host 1 incremented by one
(x+1). Note that the ACK number from Host 2 is the
sequence number that Host 1 is expecting. This prevents
duplicate messages from affecting the connection
establishment process. Figure 3.3 shows a worst case
scenario with a duplicate SYN message and an ACK
reappearing at Host 2s connection.

Figure 3.3 scenario. [7]

When Host 2 gets a duplicate SYN message it replies
accordingly as it would be a real SYN. But Host 1 will not
expect an SYN-ACK with an ACK-number of x, thus
rejecting the connection attempt. When the other duplicate

page 3 of 8

arrives at Host 2 with an ACK-number z, Host 2 knows that

this to must be a duplicate because it is expecting the ACK
number y and not z.
Also there is the problem of lost packets, packets that dont
arrive at all. This is solved by the use of timers, every time
a SYN is sent the Host is starting a timer. If the timer
reaches zero and there is no response from the other Host,
the packet is considered to be lost, and resent.

3.2.2 Connection Release

When a host decides to terminate a connection, it cannot do
so without notifying the other host. This would result in a
half open connection, which is the main concern in the
release connection phase. To avoid half open connections
we need a protocol that is similar to the three-way
handshake. Lets say that Host 1 wants to terminate the
connection with Host 2. Similar to the connection
establishment phase, Host 1 sends a Disconnection Request
to Host 2. Similar to a SYN, this is a packet with an FIN
flag set in the TCP header with no data. When Host 2
receives the disconnection request from Host 1, it also
sends an FIN packet back to Host 1. Host 1 will then
respond with an ACK. This may appear to be simple at
first, but there are some things that can go wrong here.
What if Host 1 never receives a FIN from Host 2? Should
Host 1 close the connection? Another possible scenario is
when the last ACK from Host 1 is lost. Should Host 2
release the connection anyway?
Again like lost SYN packets these are solved by using
timers. But here we do not always retransmit a
disconnection request after a timeout. Host 2 will release
the connection after the FIN has timed out, this will solve
the last lost ACK scenario and also the worst case where all
messages after the first FIN was received are lost. Host 2
can close the connection after the timeout because we know
that Host 1 will also close its connection after N
retransmission attempts. The last lost ACK problem really
doesnt matter because Host 1 has already released, and
host 2 will do so after the time out. These scenarios are
illustrated in the figure below.

Figure 3.4 Connection release. [7]

3.2.3 Sliding Window

Sliding window is a protocol for efficient transferring of
data between two connected hosts. Because always waiting
for an acknowledgement before sending the next packet of
data is not efficient, the sliding window lets a host send
several packets of data before receiving an
acknowledgement. The size of the window, tells the sender
how many unacknowledged packets it can have. The size of
the window is variable and can change during the
connections lifetime, depending on the bandwidth and
delays of the network. The point is to always have a
window size big enough so that the sender can keep on
sending until the first acknowledgement has arrived.
There are two popular versions of the sliding window
protocol, Go Back N and Selective Repeat [7]. The
difference between them is how they handle lost and
corrupt packets. Go Back N will simply discard all frames

page 4 of 8

that are received after a lost packet. After the lost packets
timer has expired the sender will retransmit it and all the
discarded frames. A more efficient way is to use selective
repeat, instead of discarding, the out of order packets are
buffered. And only the lost packets will have to be
retransmitted by the sender. For more efficiency selective
repeat can use negative acknowledgements (NAK) when it
detects that a packet must be lost. This is faster because the
sender does not have to wait for a timeout. Figure below
shows an example of Go Back N (a) and Selective Repeat
(b).

Figure 4.1 Packet size demand. [3]

There are a few assumptions from the design of the TCP
protocol that are needed to be remembered in order to set
the future [2]:

TCP has been designed for a wired network but

these days the dominion of wireless networks is
irrefutable. The main problem with wireless
networks is that they have a higher bit error rate
(BER) than wired networks. This brings packet
losses due to network congestion which is not
anymore a problem of just bit-level corruption.

TCP protocol understands that there is only one

best way of routing since packet reordering is
considered to occur in a minor scale. All the
packets are expected to follow the same path in
their way through the network.

The network is supported by physical circuits with

a limited bandwidth and TCP works under this
rule. TCP considers the bandwidth constant and
uses an end-to-end control loop for sending rates.
If the bandwidth is changing in time TCP may
take decisions with less risk for data loss.

Buffers have first-in first-out (FIFO) philosophy

and TCP is more effective if the buffer size that
resolves connections within the switches is in the
same order of magnitude of the bandwidths delay,
as a result of the associated link.

Session duration makes a strong impact on TCPs

efficiency which assumes that every TCP session
has a specific number of time slots. The
developing of short term sessions in applications
such as short Web transfers makes more damage
with an everyday more obsolete transport control
protocol.

Figure 3.5 Sliding window. [7]

4. Future TCP/IP
According to the metrics presented by Claffy [1], While
almost 60% of packets are 44 bytes or less, constituting a
total of 7% of the byte volume, over half of the bytes are
carried in packets of size 1500 bytes or larger. These
results mean that even during the young period of the
internet (year 1998) the volume of packets was growing
fast as the demand of the users and the amount of them was
developing logarithmically. The demand is bigger and more
exigent nowadays. Media, streaming, p2p and other
services with an important load of traffic with heavy
content are the users needs to be covered. TCP will not be
able to support an upcoming demand of larger packages as
shown in Figure 4.1.

page 5 of 8

Large payloads take place when there is a low

bandwidth and the usual 40 bytes per packet
overhead is assumed too inefficient.

Interaction with other TCP sessions is a strategy

planed to optimize the network. As it is planed
every TCP session shares bandwidth with other
connections but this interaction does not work
properly with flow-control protocols which
derives in unpredictable results and poor network
efficiency.

4.1 Future TCP

4.1.1 Modified TCP stacks
Recently, several new protocols have made their presence
in collaboration with Web server systems which stacks can
interoperate with the regular TCP clients. This offers
superior download ability over the traditional TCP. This is
possible due to some changes in the flow control systems of
TCP. According to [2] The modified implementation may
use a lower initial RTT estimate to provide a more
aggressive startup rate, and a more finely grained RTT
timer system to allow the sender to react more quickly to
network state changes. This kind of modification in the
implementation as well as using a larger window size or
changing the slow-start mode can produce favorable
sending rate, up to triple in respect to previous version.
This complex technique may force network buffers
increasing pressure on them and forcing users to act more
aggressive in their package transmissions. This aggressive
behavior reduces traditional TCP sessions sending rate,
opens additional space in the network and increases selfsending rate.
Despite this visible upgrade of the protocol into a dynamic
equilibrium due to cooperation between sending systems
the number of packet losses increase using these methods
because forcing the network to saturation with its own
packets produces less sensitivity to network congestion
metrics.
The consequence of large volume of packet transmissions
from one session being lack of pressure from competitor
sessions is a less efficiency of the modified TCP stack than
the standard TCP. In the production environment the
imposition of penalties to concurrent TCP sessions
indicates that the modified TCP stacks should be preserved
only for private use networks because its benefit to the
public Internet is in doubt.

low network efficiency of the traditional TCP with the

advantage of low jitter retransmission we have to take a
compromise solution. Coherency needs to be preserved to
keep the balance in the network, interaction between
protocols and data flow between these different uses of
similar architectures. Flexible changes may come to the
transport protocols with a continuous innovation. The
acceptable changes are driven under the trust between the
competing user demands and not by the rigid rules of
sharing networks.

4.1.3 FAST TCP

In 2003 a group of scientist from different universities and
private companies published their investigations and results
about a new TCP congestion control algorithm for highspeed long-latency networks [6]. The work has its basis on
the fact that the availability of resources and the set of
competing users vary over the time unpredictably. It was
necessary to use feedback control tools to adapt
dynamically the rates of congestion.
The solution adopted was using a delay-based congestion
control because queuing delays provide more accurate
results than loss probability and packet loss in networks
since these phenomenons are unusual. While packet loss
provides only one bit of information plus noise, queuing
delays have multi-bit information. This way an equation for
stabilization at steady state is easier to formulate.
Here are presented some problems that appear at large
windows: packet and flow level modeling, equilibrium,
dynamics. According to [3] The window
of source
i increases by 1 packet per RTT and decreases per unit time
by

packets where

pkts/sec. being
the round-trip time and
is the
(delayed) end-to-end loss probability, in period t. As long
as the mathematical explanation develops two equations
describe flow-level dynamics and equilibrium. There are
currently other algorithms to improve congestion control
such us HSTCP, STCP and Reno. Despite their different
aspect they all have similarities concerning structure and
dynamics at flow-level. Their congestion windows evolve
all according to:

4.1.2 TCP Evolution

As it has been shown in the comparison of traditional TCP
and modified TCP stack there is a balance to keep between
network congestion collapse and innovation avoiding
competing protocols get into race under no control. Under
tests with the more aggressive TCP optimized advances
which result in congestion collapse of the network and the

page 6 of 8

The controllable parameters are:

: gain, controls stability and responsiveness and
does not affect equilibrium properties.

: marginal utility function, controls equilibrium

rate allocation and its fairness.
: congestion measure, is limited to loss probability or
queuing delay and its dynamics are set up inside the
network.
The equilibrium at large window is difficult to maintain in
practice because the bandwidth-delay product increases. It
has been tested that when a source increases its window too
slowly decreases too drastically, which is a problem for
equilibrium. This causes an oscillatory behavior at packet
and flow level. At packet level, bottleneck queues get
worse as bandwidth-delay product increases. On the other
hand, at flow level, system dynamic are unstable at large
bandwidth-delay products. To solve this there must be
multi-bit feedback but some problems at flow level can be
still distinguished: equation-based control which needs
explicit estimation of end-to-end probability and the other
one is flow dynamics. Flow dynamics can bring instability
to feedback as feedback delay increases.

4.1.6 Most modern TCP works

The latest reviews in TCP protocol [9] show that a
compromise solution must be adopted between the different
new TCP implementations as shown in Table 1.

4.1.4 The Delay-based solution

What determines the variations on the network as it
increases its capacity, are the dynamics of the feedback
system, and must be balanced in presence of delay. Another
advantage over loss probability is that dynamics are scaled
to fit networks capacity as it grows. The delay-based
solution estimates the distance of the state from the
equilibrium point 1.

4.1.5 Architecture
According to [6] TCP congestions control protocol is split
into four independent functionally components:
Data control: determines which packets to transmit.
Window control: determines how many packets to transmit.
Business control: determines when to transmit.
Estimation component: takes decisions to control the other
three components.
This last component meant to rule the others handles two
fragments of feedback information for every packet sent.
One is a multi-bit queuing delay and the other one is a onebit loss-or-no-loss flag, understanding flag as an indicator.
These two separate pieces of information are used by the
other three components. Data control chooses the next
packet to send from 3 different sources: new packets,
packets with negative acknowledgement, and packets
already transmitted but not acknowledged. Packet
regulation at RTT time domain is done by window control.
Finally business control makes the transmission fluent
according to the available bandwidth. To fulfill FAST TCP
two extra mechanisms are used one to supplement selfclocking in streaming out individual packets and the other
to increase window size smoothly in smaller bursts. A
detailed explanation can be found at [6].

page 7 of 8

Table 1 TCP Most modern implementations. [9]

4.2 Future IP
It is on some developers mind the future of mobile
communications an IP based network that will be part of
the 4G Mobile Networks. This forces to make
improvements to change from the traditional packetswitched networks to a packet based wireless IP network
and also is seen as the motor-breath for new
communication systems and technologies development.
The infrastructures of a wireless network are not so much
physically dependent as wired networks, which brings
economic and security issues to debate just to come up with
a compromise relation between users and operators.
As is explained by Kurtansky [3] in his paper, AAAC Arch.
stands for Authentication, Authorization, Accounting and
Charing Architecture. According to the paper this
architecture has been implemented to facilitate the
deployment of a ubiquitous mobile IPv6-based, QoS-aware
infrastructure through a flexible and evolutionary AAAC
Architecture.
In order to give support to both AAAC client and AAAC
server [3] focuses on both DIAMETER client and
DIAMETER server. Client daemon is in charge of
accepting registration requests and forwarding to the server
daemon. It uses User Registration Protocol (URP) and
DIAMETER protocol. The server daemon has the task of
authentication, authorization, and accounting based on the
user profile information as show in Figure 4.2.

6. REFERENCES
[1] Claffy, K., Miller, G., Thompson, K.,(1998), The

Nature of the Beast: Recent Traffic Measurements

from an Internet Backbone, INET'98 Proceedings,
Internet
Society.
Available
at:
http://www.isoc.org/inet98/proceedings/6g/6g_3.htm.
[2] Huston G., Telstra (2000), The future of TCP, The

internet protocol Journal, Cisco Systems, Vol.3, N3.

[3] Kurtansky, P. et al (2004), Extensions of AAA for

Future IP Networks, IEEE Communications Society,

Computer Engineering and Networks Lab TIK, Zrich,
Switzerland; Institute FOKUS, Berlin, Germany;
Universidad Carlos III Madrid, Spain; University of
Stuttgart, Germany.
Figure 4.2. AAAC System. [3]

[4] Postel, J. (1981), Transmission Control Protocol, RFC

793.
[5] University of South California (1980), DOD Standard

Internet Protocol, RFC 760.

5. Results and Conclusion

Since the giant step growing of the internet in the late
1990s it has been demonstrated that TCP protocol may
evolve into a more flexible protocol. Since upcoming
protocols such as modified TCP stacks appeared it has been
tested that a balance must to be kept between network
sharing with other competing protocols and innovations in
these new protocols, in order not to get network congestion
collapse.
Fast TCP discards the old loss probability model and uses a
delay-based model. A balanced zero-state is set at the delay
queue which tries to control flow-level and bandwidth. A
multi-bit feedback control system is used to be more
accurate than the regular TCP.
It is a fact the 4G Mobile Networks will be IP-based and
this new concept of communications technology gives a
new role to the internet protocol.
The complexity of networks evolution grows in parallel to
the digitalization era started in the 1990s. The only way to
support the strong increase of users demand and the fast
technological development lies on a twist on the concept of
the future networks. To cover future needs we have to
implement a cohesion point from improved actual tools.
That is the reason why extreme changes are not accepted.
Using IP as the protocol for 4G Mobile Networks is an
example of technology improvement with improved actual
tools. FAST TCP shows how a twist in the observer
perspective, since a scientific point of view, can bring
important developments without using new technological
advances but a better knowledge of mathematics.

page 8 of 8

[6] Wei D. et al, (2004), Fast TCP, Engineering &

Applied Sciences, Caltech.

[7] Tanenbaum,

Andrew S. (2003-03-17). Computer

Networks (Fourth ed.). Prentice Hall. ISBN 0-13066102-3. :Chapter 3.4 and 6.

[8] Cerf, V. , and R. Khan, A Protocol for Packet

Network Intercommunication (1974)

[9] B. Qureshi, M. Othman,(2009),Progress in Various

TCP variants, IEEE, and N. A. W. Hamid.