TRANSPORT CONTROL PROTOCOL

October 19th, 1998

Kimmo Ahonen

Kimmo.Z.Ahonen@ntc.nokia.com

 

Juha Koskelainen

Juha.Koskelainen@ntc.nokia.com

Department of Computer Science

University of Helsinki

Abstract

Aim of this paper is to present transmission control protocol of Internet (TCP) and demonstrates some of the problems in modern networks while using TCP.

 

 

1 Introduction to the paper

2 The OSI Model

2.1 TCP/IP Implementation hierarchy

3 The Transmission Control Protocol (TCP)

4 TCP Standard

4.1 The basic data transfer

4.2 Reliability

4.3 Flow Control

4.4 Multiplexing

4.5 Connections

4.6 Precedence and security

5 TCP operations

5.1 TCP Message Format

5.2 Sequence numbers

5.3 Opening a connection

5.4 Closing a connection

5.5 Option bits

5.6 PSH bit

5.7 URG bit

6 TCP Congestion control

6.1 Window Management

6.2 Slow start

6.3 Dynamic window sizing

6.4 Fast retransmit

6.5 Fast recovery

7 Future directions

7.1 IPv6

7.2 Option bits

8 Current problems with TCP

8.1 TCP versus lower layer protocol’s congestion control

8.2 Quality of Service

8.3 Transactions

8.4 Asymmetry of the network

9 TCP implementation policies

9.1 Send policy

9.2 Deliver policy

9.3 Accept policy

9.4 Retransmit policy

9.5 Acknowledge policy

9.6 Real implementations of TCP

9.6.1 TCP Reno

9.6.2 TCP SACK

10 Wireless TCP

10.1 Snoop protocol

10.2 Indirect TCP

10.3 Mowgli architecture

11 TCP over ATM

11.1 TCP over UBR

11.1.1 Partial packet discard policy

11.1.2 Early packet discard policy

11.1.3 Selective packet dropping policy

11.1.4 Early packet discard policy with fair buffer allocation

11.2 TCP over ABR

11.3 Conclusion

Appendix 1

References

1. INTRODUCTION TO THE PAPER

The internetwork environment consists of hosts connected to networks that are in turn interconnected via gateways. The networks may be either Local Area Networks (LAN) or Wide Area Networks (WAN).

Within a business organization at a single location, the computer network is usually LAN. When the business organization needs to communicate with other business or individuals at a different location, a WAN network is created to connect the different sites together. These different types of networks are often connected by using TCP/IP protocol.

The TCP/IP protocols correspond to the Transport layer and Network layer of the OSI model. The TCP/IP protocol suite defines two standard transport protocols: TCP and UDP. TCP (Transmission Control Protocol) implements a reliable data-stream protocol, whereas UDP (User Datagram Protocol) implements an unreliable data-stream protocol.

Both TCP and UDP run on top of the Internet protocol and build the services by IP. IP provides a connectionless datagram service between two computers. By using TCP and UDP data can be delivered not to a remote computer, but to an application process running on the remote computer. These application processes are identified by port numbers.

TCP can ensure that data is delivered reliably to the destination by providing a connection-oriented service. UDP is connectionless and cannot guarantee delivery of data [1].

2. The OSI Model

The OSI Reference Model was developed by the International Organization of Standards (ISO). It is used to describe the flow of data between the physical connection to the network and the end-user application. OSI Model is used for the development of open systems and as a yardstick to compare different computer communications systems.

The OSI layers are numbered to represent the functionality of the layer. The numbering is from bottom to top. The most basic functions, such as putting data bits onto the network cable, are on the bottom. Functions attending to the details of applications are at the top. The following picture shows different layers of the OSI layering model.

7. Application layer

6. Presentation layer

5. Session layer

4. Transport layer

3. Network layer

2. Data Link layer

1. Physical layer.

In the OSI model, the purpose of each layer is to provide services to the next higher layer, shielding the higher layer from the details of how the services are actually implemented. The following list describes the purpose of each of the seven layers of the OSI model and identifies services that they provide to adjacent layers [2].

1. The Physical layer transmits bits over a communication channel [3]. The Physical layer relates the electrical/optical, mechanical, and functional interfaces to the cable. It also carries the signals that transmit data generated by all the higher layers [2].

2. The Data Link layer builds on the transmission capability of the Physical layer and provides services to the Network layer. The bits that are transmitted or received are grouped in logical units called a frame. In the context of LANs, a frame could be a Token Ring or Ethernet frame, an FDDI (Fiber Distributed Data Interface) frame, or another LAN type frame. For WAN links, this could be a SLIP (Serial Line Interface Protocol), PPP (Point-to-Point Protocol), X. 25, or an ATM (Asynchronous Transfer Mode) cell frame or another WAN type frame [3].

3. The Network layer builds on the node-to-node connection provided by the Data Link layer. Network layer provides additional service how to route packets (units of information at the network layer) between nodes connected through an arbitrarily complex network.

Besides routing, the Network layer helps to eliminate congestion as well as regulate the flow of data. The Network layer also makes it possible for two networks to be interconnected by implementing a uniform addressing mechanism [3].

4. The Transport layer provides enhancements to the services of the Network layer. This layer helps ensure reliable data delivery and end-to-end data integrity. To ensure reliable delivery, the transport layer builds on the error control provided by the lower levels [3]. If the lower layers cannot provide error free data flow, the Transport layer has to resolve data errors.

5. The Session layer allows two applications on different computers to establish, use, and end a connection called a session. The layer performs name recognition and the functions needed to allow two applications to communicate over the network, such as security functions.

6. The Presentation layer managers the way data is represented. Many ways of representing data exist, such as ASCII and EBCDIC for text files. Many TCP/IP applications do not use any Presentation layer services and the Presentation layer is null for these applications [3].

7. The Application layer contains the protocols and functions needed by user applications to perform communication tasks. These protocols provide different services for user applications to interact with computer network.

Many of these services are called Application Programming Interfaces (APIs). APIs are programming libraries that an application writer can use to write network applications.

Two computer systems involved in the data exchange are called End Systems (ES) in OSI terminology. The application layer in each ES performs processing and adds some application information as header information to the message. In every layer some more processing information are added to the to the message. The following picture shows an example of how data traverses the network.

Figure 1: Data traversal in the network layers

The OSI model provides a conceptual view of communication that is easy to comprehend. In actual practice, the layers are not as well defined as shown in the OSI model. An implementation, for example, may not have a distinct separation between Presentation and Application layer. Many of the functions of the Presentation layer, such as universal data encoding and decoding, may be performed in the Application Layer by calling appropriate data encoding and decoding programming language functions [3].

2.1 TCP/IP Implementation hierarchy

TCP/IP implementation hierarchy differs slightly from OSI model. There exists also a DoD (Department of Defense) model, which has less divisions than OSI model. The following model summarizes protocols related to internetworking and TCP [1]:

Figure 2: TCP/IP implementation hierarchy

Different applications use services provided by TCP, UDP and IP. Even though TCP and UDP are higher level protocols than IP applications can use IP directly. Some examples of TCP level applications are File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), TELNET and Simple Mail Transfer Protocol (SMTP). Examples of protocols that run on the top of UDP are Trivial File Transfer Protocol (TFTP) and Simple Network Management Protocol (SNMP). Network File System (NFS) is an example of protocol that can run on either TCP or UDP.

TCP/IP can run on top of many lower level protocols.

3. The Transmission Control Protocol (TCP)

The TCP protocol provides a standard general-purpose method for reliable delivery of data. For applications TCP provides a standard way of accessing remote computers on unreliable internetwork. This reliability is provided by adding services on top of IP. IP is connectionless and does not guarantee delivery of packets.

The reliability of TCP is achieved by retransmitting data, which has been sent but not acknowledged by receiver within given time. Thus sending TCP must keep the sent data in memory until it has received the acknowledgements of sent data.

TCP assumes that IP is inherently unreliable, so TCP adds services to ensure end-to-end delivery of data. TCP has very few expectations on the services provided by the networks and it thus can be run across a large variety of hardware. All that is required from lower level is unreliable datagram service.

TCP is the primary transport protocol used to provide reliable, full-duplex, virtual circuit connections. The most common use of TCP is to run it over IPv4 or IPv6, although several experimental projects have been done to run TCP on other Network layer protocols [4].

IP is implemented on hosts and routers. TCP is typically implemented on hosts only. Today, many routers are implemented with TCP protocol to provide easy configuration and management. For example, many commercial routers implement TCP or UDP to provide remote login and network management facilities. Even though TCP and UDP are implemented in routers, the transport protocols are not used by routing services and messages. This is illustrated in the following picture.

Figure 3: TCP protocol on network

4. TCP Standard

TCP standard is defined in RFC 793 in 1981. The primary purpose of the TCP is to provide reliable, securable logical circuit or connection service between pairs of processes [4]. This security is based on assumption that the underlying network can be trusted, which is not the case in the current commercial Internet. The statement secure comes from the time, when TCP/IP was primarily used for Military purposes.

TCP provides reliable services on top of a less reliable internet communication systems on following areas [4]:

The basic operation of the TCP is described in following sections [4].

4.1 The basic data transfer

The TCP Basic Data Transfer is able to transfer a continuous stream of octets in each direction between its users by packaging some number of octets into segments for transmission through the internet system. The octets are sent among application processes running on remote systems that use TCP. In general, the TCPs decide when to block and forward data at their own convenience [4].

The application processes group a set of bytes that need to be sent or received into a message segment. Message segments can be arbitrary length. At the TCP level there is no real restriction on message size because the details of accommodating the message segments in IP datagrams is the task of the IP layer.

Ultimately, the messages have to be sent in IP datagrams that are limited by the MTU (Maximum Transfer Unit) size of a network interface. For efficiency reasons TCP connections typically negotiate a maximum segment size.

Messages sent by TCP have an octet orientation. TCP keeps track of octets that has been sent or received. The TCP does not have any notion of a block of data. This differs from many other transport protocols, which typically keep track of the Transport Protocol Data Unit (TPDU) number and the octet number. TCP can be used to provide multiple connections between two host computers.

Application processes are allowed to send data whatever size that is convenient for sending. For example, an application can send one octet at a time or several kilo octets. TCP numbers each octet that is send. The octets are delivered to the application layer in same order that they are sent.

An application can send data to TCP a few octets at a time. TCP buffers this data and sends these octets either as a single message or as several smaller message segments. All that TCP guarantees is that data arrives in the order in which it was sent.

The actual data that is sent by TCP is treated as an unstructured stream of octets. TCP does not contain any facility to superimpose an application dependent structure on data. The structuring of data must be handled by the application processes that communicate by using TCP.

4.2 Reliability

The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within the timeout interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order. Damaged segments are handled by adding a checksum to each segment transmitted. The receiver verifies the checksum discarding damaged segments. Unless there is a physical break in the link that causes physical partitioning of the network, TCP is able to recover most internet communications system errors.

4.3 Flow Control

TCP provides a means for the receiver to govern the amount of data sent by the sender. Computers that send and receive TCP data segments can operate at different data rates because of differences in CPU and network bandwidth. As a result, it is possible for sender to send data at a faster rate than the receiver can handle.

TCP implements a flow control mechanism that controls the amount of data send by the sender. This is achieved by using a sliding window mechanism. The receiver TCP module sends back to the sender an acknowledgment that indicates a range of acceptable sequence numbers beyond the last successfully received segment. This range of acceptable sequence numbers is called a window.

The window size reflects the amount of buffer space available for new data at the receiver. If this buffer space size shrinks because the receiver is being overrun, the receiver will send back a smaller window size. In the extreme case the windows size will decrease to very small or one octet. This is referred to as the silly window syndrome. Most TCP implementations take special measure to avoid it.

The goal of the sliding window mechanism is to keep the channel full of data and to reduce the delays for waiting acknowledgements.

4.4 Multiplexing

TCP enables many processes within a single host computer to use TCP communications simultaneously. Different processes may be communicating over the same network interface. Thus they must be separated from each other. This separation is done by using different port numbers for each process. Port numbers are concatenated with network and host addresses from the internet communication layer, this forms a socket.

A pair of sockets uniquely identifies a connection. Multiple connections can be used to enable several connections between application processes on remote computers. The binding of ports to processes is handled independently by each computer. Frequently used processes are attached to fixed sockets, which are made known to the public.

4.5 Connections

The reliability and flow control mechanisms require that TCPs initialize and maintain status information for data streams. The combination of the sockets, sequence numbers and window sizes is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides.

The TCP connection is identified by the parameters of both end points:

(IP address 1, port number 1, IP address 2, port number 2)

These parameters make it possible to have several application processes that connect to the same remote end point [4].

Port number is a 16-bit value. This means that port numbers can vary in the range of 0 to 65535. Some of these port numbers are listed on the following table [3, 5]:

Table 1: Port numbers

Protocol

Number

Application Layer Service

TCP/UDP

0

 

TCP/UDP

7

Echo

TCP/UDP

9

Discard

TCP

17

Quote of the Day (QUOTD)

TCP

20

FTP Data Port

TCP

21

FTP Control Port

TCP

22

SSH - Secure Shell

TCP

23

Telnet

TCP

25

SMTP

TCP/UDP

53

Domain Name Server (Domain)

UDP

67

Bootstrap Protocol Server (bootps)

UDP

68

Bootstrap Protocol Client (bootpc)

UDP

69

Trivial Transfer Protocol (tftp)

TCP/UDP*

79

Finger protocol

TCP/UDP*

80

HTTP Hyper Text Transfer protocol (World Wide Web)

TCP/UDP*

110

Post Office Protocol - Version 3 (POP3)

TCP/UDP*

137

NETBIOS Naming Service (netbios-ns)

TCP/UDP*

138

NETBIOS Datagram Service (netbios-dgm)

TCP/UDP*

139

NETBIOS Session Service (netbios-ssn)

UDP

161

Simple Network Management Protocol (SNMP)

TCP

443

HTTPS - HTTP over SSL/TLS

TCP

513

Remote Login

TCP

515

LPR/LPR printing

UDP

1512

Microsoft WINS

TCP

1525

Oracle SGL*net v1

TCP

6000-6063

X11 protocol

*Teleware training material [5] specifies this as TCP only. Inside TCP/IP book specifies this as both TCP/UDP.

Port numbers on the range 0..1023 are called well-known port numbers. Many publicly available TCP/IP applications use port numbers on this well-known range.

4.7 Precedence and security

RFC 793, where TCP was originally specified, states precedence and security:

The users of TCP may indicate the security and precedence of their communication. Provision is made for default values to be use when these features are not needed [4].

This assumption was made when the network was assumed to be secure. In these days the network cannot be trusted. Internet messages can be read by virtually anybody.

5. TCP operations

TCP is implemented as a protocol module that interacts with the computer's operating system. In many operating systems, the TCP module is accessed like the file system of the operating system. The TCP module depends on other operating system functions to manage its data structures and services. The interface to the physical network is controlled by a device driver module. TCP does not communicate directly to device driver. IP module acts as a middle layer in TCP communication to the network driver.

From the abstract viewpoint, applications will interface with the TCP module with the following system calls [4]:

OPEN to open a connection

CLOSE to close a connection

SEND to send data to an open connection

RECEIVE to receive data from an open connection

STATUS to find information about a connection

These calls are much like operating system's file system calls. The connection must be established before it can be used, as is with operating system files.

5.1 TCP Message Format

TCP segments are sent as internet datagrams. The Internet Protocol header carries several information fields, including the source and destination host addresses [4]. A TCP header follows the internet header, supplying information specific to the TCP protocol. This division allows for the existence of host level protocols other than TCP.

Figure 4 TCP header format

 

Table 2 TCP header specification

Source port:

16 bits

The source port number

Destination port:

16 bits

The destination port number

Sequence Number (SEQ):

32 bits

The sequence number of the first data octet in this segment (except when SYN is present) If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1

Acknowledgement Number (ACQ):

32 bits

If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent.

Data Offset:

4 bits

The number of 32 bit words in the TCP header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long.

Reserved:

6 bits

Reserved for future use. Must be zero.

Control bits:

6 bits (from left to right)

 

 

URG:

Urgent Pointer field significant

 

ACK:

Acknowledgement

 

PSH:

Push function

 

RST:

Reset the connection

 

SYN:

Synchronize sequence numbers

 

FIN:

No more data from sender

Window:

16 bits

The number of data octets beginning with the one indicated in the acknowledgement field which the sender of this segment is willing to accept.

Checksum:

16 bits

Checksum field is calculated to verify the data correctness.

A TCP connection progresses from one state to another in response to events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS; the incoming segments, particularly those containing the SYN, ACK, RST and FIN flags; and timeouts [4].

5.2 Sequence numbers

A TCP connection numbers every octet sent with a unique sequence number. Acknowledgement of received octets can be directed to these sequence numbers directly. The acknowledgement mechanism employed is cumulative so that an acknowledgement of sequence number X indicates that all octets up to but not including X has been received. Numbering of octets within a segment is that the first data octet immediately following the header is the lowest numbered, and the following octets are numbered consecutively [4].

The acknowledgement number and sequence numbers are 32 bits wide. The biggest possible number is very large, but not infinite. All arithmetics dealing with sequence numbers must be modulo 2**32. This means that when number space overflows it starts from 0 again.

The initial sequence number can be chose quite freely for connection. It should be kept in mind that previous segments might be traversing in the network, while new connection is established. Thus is used a fictious 32 bit clock which low order bit is incremented approximately every four microseconds. Thus the initial sequence number is cycled approximately every 4 hours.

To be sure that a TCP does not create a segment that carries a sequence number which may be duplicated by an old segment remaining in the network, the TCP must keep quiet for a maximum segment lifetime (MSL) before assigning any sequence numbers upon starting up or recovering from crash. For this specification the MSL is taken to be 2 minutes [4].

A TCP connection has to be cautious about not using the same sequence numbers again, because a sequence number and socket specifies data uniquely. If sequence numbers are reused by connection too quickly the receiver might mistakenly replace the original data with different one.

Under normal conditions, TCPs keep track of the next sequence number to emit and the oldest awaiting acknowledgement so as to avoid mistakenly using a sequence number over before its first use has bee acknowledged. This does not itself guarantee that old duplicate data is drained from network, before a new octet arrives with the same sequence number. At 2 megabits/s it takes 4.5 hour to use up 2**32 octets of sequence space. Since the maximum lifetime in the net is not likely to exceed a few tens of seconds, this was seen to be adequate by designers of TCP protocol. It is also enough for higher speed networks with 10 and 100 megabits/s. For 100 megabits/s the cycle time is 5.4 minutes, which is still adequate.

Gigabit networks consume sequence numbers too rapidly in order TCP to operate in them properly. The RFC 1323 specifies extensions to RFC 793 to suit TCP for very high-speed paths [6]. Currently it is at proposed standard phase.

5.3 Opening a connection

The procedures to establish connections utilize the synchronize (SYN) control flag and involves an exchange of three messages termed the three-way handshake. A connection is established by OPEN calls to the local port. This open can be either active or passive.

In an active OPEN call, the connection establishment is to be actively initiated. An active OPEN call is generated when an another end point is contacted. A passive OPEN call signals an intent to receive an active OPEN connection. It does not generate a TCP message segment. A passive OPEN request means that a process wants to accept incoming connection requests rather than attempting to initiate a connection.

If two processes issue active OPENs to each other at the same time, they will be correctly connected.

The three way handshake is the procedure used to establish a connection. This procedure is initiated by one TCP and responded by another TCP. The procedure also works if two TCP simultaneously initiate the procedure.

In case of single TCP open connection three way handshake works as:

The procedure is illustrated in the following example.

1.

CLOSED

 

 

 

LISTEN

2.

SYN-SENT

Þ

SEQ=100 (ISN),SYN.bit=1

Þ

SYN-RECEIVED

3.

ESTABLISHED

Ü

SEQ=300 (ISN+Window+1), ACK=101, SYN.bit=1,ACK.bit=1

Ü

SYN-RECEIVED

4.

ESTABLISHED

Þ

SEQ=101, ACK=301, ACK.bit=1

Þ

ESTABLISHED

5

ESTABLISHED

Þ

SEQ=101, ACK=301, ACK.bit=1, DATA

Þ

ESTABLISHED

Figure 5. The three way handshake

After the connection has been established data can be sent. In the every segment the receiver describes how many octets of data it is ready to receive. Thus the window size can be dynamically adjusted.

5.4 Closing a connection

CLOSE is an operation meaning that there is no more data to be sent. The closing can be done in three fashions:

In the first case, a FIN segment can be constructed and placed on the outgoing segment queue. At this state the TCP will not accept any more SENDs from application. RECEIVEs are allowed at this state. When the other TCP has both acknowledged the FIN and sent a FIN of its own, the first TCP can ACK this FIN. Note that a TCP receiving a FIN will ACK but not send its own FIN until its user has CLOSED the connection [4].

At the second case an unsolicited FIN arrives from the network. The receiving TCP can ACK it and tell the user that the connection is closing. The user will respond with a CLOSE, upon which the TCP can send a FIN to the other TCP after sending any remaining data. The TCP then waits until its own FIN is acknowledged whereupon it deletes the connection. If an ACK is not forthcoming after the user timeout the connection is aborted.

A simultaneous CLOSE by users at both ends of a connection causes FIN segment to be exchanged. When all segments preceding the FINs have been processed and acknowledged, each TCP can ACK the FIN it has received. Both will, upon receiving these ACKs, delete the connection.

A connection can be closed also by resetting it. This should not be used as a means to normally close a connection. This is done by setting RST bit (reset) indicating that the TCP closes the connection without negotiation and the receiver should delete the connection without further interaction. As a general rule, reset must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case.

5.5 Option bits

There have been specified three different options. Option may occupy space at the end of the TCP header and are multiple of 8 bits in length. All options are also included in the checksum. These options are listed, only the first one has been specified in original RFC 793:

Maximum Segment Size: In the initialization of connection the maximum segment size can be specified.

Window Scale Factor: Originally, the Window field in the TCP header gives a credit allocation in octets. When the window scale factor is in use, the value in the Window field is multiplied by a 2**F, where F is the value of the window scale option. The maximum value of F that TCP accepts is 14. This option is only used in the initial connection request segments [7]. This option allows the window size to enlarged beyond 16-bit scale.

Timestamp: This option can be used in any data segment and defines two optional fields. Timestamp field is used to continuously monitor roundtrip time of a connection.

5.6 PSH bit

PSH bit is used to indicate for TCP that it must act upon the data that it has received so far. When an application process issues a series of SEND calls without setting the PSH bit, the TCP can aggregate the data internally without sending it. Similarly, when a series of segments is received without the PSH bit, a TCP can queue the data internally without passing it to the receiving application.

An application program is required to set the PSH flag in a SEND call whenever the program needs to force deliver of the data to avoid a communications deadlock. A TCP should use a maximum segment size to improve performance whenever possible. This may result that the data is not immediately delivered to receiving application.

At the receiver, the PSH bit forces buffered data to be delivered to the application. Normally the buffer is delivered to the application whenever the buffer is full.

5.7 URG bit

TCP contains a mechanism to send out band of data using a URG bit. This is used to deliver data immediately to the receiving application. This segment bypasses any data on the queue and it must be processed immediately.

6. TCP Congestion control

Congestion in a network or internet creates problems for the end systems: reduced availability and throughput and lengthened response times. Within a switched network, such as a packet-switching or frame relay network, dynamic routing can be used to alleviate congestion by spreading the load more evenly.

Due to the variances in network performance the retransmission of octets affects TCP congestion. TCP maintains a queue of segments that have been sent but not yet acknowledged. The TCP specification states that TCP will retransmit a segment if it fails to receive an acknowledgement. By dynamically adjusting retransmission time sending TCP have an impact on network congestion. If a TCP sends data too soon, when congestion occurs, the retransmitted data increases the congestion in the network.

6.1 Window Management

In addition to techniques for improving the effectiveness of the retransmission strategy, a window management approaches have an effect of congested network. These methods are described in RFC 2001, which is currently in proposed standard phase:

6.2 Slow start

The larger the send window used in TCP, the more segments that a TCP source can send before it must wait for an acknowledgement. In the ordinary course of events, the nature of TCP paces the operation appropriately. This is that when data is transmitted over slow connections the send speed adjusts automatically according to the connection. This is called the self-clocking nature of TCP.

Slow start operates by observing that the rate at which new packets should be injected into the network is the rate, which the acknowledgements are returned by the other end [8]. When a new connection is opened, the TCP entity is only allowed to send one segment at a time [7].

Slow start adds another window to the sender's TCP: the congestion windows, called cwnd [8]. This congestion window tells how many segments can be sent before wait for ACKs. When a new connection is established with a host on another network, the congestion window is initialized to one segment (i.e., the segment size announced by the other end, or the default, typically 536 or 512) [8].

The sender starts by transmitting one segment and waiting for its ACK. When that ACK is received, the congestion window is incremented from one to two, and two segments can be sent [8]. The congestion window can be expanded by the power of two for every successful ACK.

In effect, the slow-start mechanism probes the internet to make sure that it is not sending too many segments into an already congested environment. As acknowledgements arrive, TCP is able to open up its window until the flow in controlled by the incoming ACKs rather than cwnd.

At some point the capacity of the internet can be reached, and an intermediate router will start discarding packets. This tells the sender that its congestion window has gotten too large.

According to "High Speed Networks" slow start method has been found to work effectively for initializing a connection. This is true if data is sent on large blocks at a time. If the data is sent as multiple small packets at a time, the slow start scheme in fact slows the operation. This is the case when WWW pages are viewed on the internet.

Most WWW pages consist of multiple small data packets, which are sent one at a time. All graphic objects on a page form an individual file, which are sent separately to the viewer. There are two standards versions that can be used when sending the information HTTP 1.0 and HTTP 1.1. Most HTTP 1.0 implementations send the information one at a time, where for every object the slow start mechanism is used. HTTP 1.1 is able to send the whole set of information once, thus the slow start scheme is used only once [5].

6.3 Dynamic window sizing

At some point, either before or after cwnd reaches the size of the credit allocated by the other side, a segment is lost. This signals that congestion is occurring. It is not clear how serious the congestion is [7]. But when congestion occurs TCP must slow down transmission rate of packets into the network [8].

In case congestion occurs the cwnd is set to 1. The network recovers from congestion slowly, and thus the slow start scheme is too rapid on congested network. If the exponential growth of packets were used on congested network, the situation would get worse.

Congestion avoidance and slow start require that two variables are maintained for each connection: a congestion window, cwnd, and a slow start threshold size, ssthresh. The combined algorithm operates as follows:

The congestion control mechanism has a linear growth compared with slow start's exponential growth.

6.4 Fast retransmit

When TCP send a message, it waits for acknowledgements to come back before it can advance its window [3]. The time delay varies between successive transmissions in TCP and an adaptive method is used in calculating retransmission timer (RTO). Smoothed Round Trip Time (SRTT) is used to calculate estimated round trip time. This value is set somewhat greater than estimated RTO.

Jacobson has proposed two procedures, called fast retransmit and fast recovery to improve the performance provided by RTO. Fast retransmit takes advantage of the following rule in TCP. If a TCP entity receives a segment out of order, it must immediately issue an ACK for the last inorder segment that was received. TCP will continue to repeat this ACK with each incoming segment until the missing segment arrives in its buffer. When the hole is plugged, TCP send a cumulative ACK for all of the in-order segments received so far [7].

Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost [8].

6.5 Fast recovery

When a TCP entity retransmits a segment using fast retransmit, it knows or assumes than a segment was lost, This is even though it has not yet timed out on that segment. Accordingly, the TCP entity should take congestion avoidance measures.

This is not the case if ACKs have returned. It indicates that data segments are arriving at the other end rather regularly. In this case the cwnd is cut in half, and then is proceeded with linear growth of cwnd. This technique avoids the initial exponential slow-start process.

7. Future directions

The internet has very rapid growth in the foreseeable future. The original specification of RFC has been stated as early as 1981. During the time the computer connections were only a fraction of current spread of data communications. Also the computing power were then only a fraction of current one.

Protocols TCP, UDP and IP has allowed the current internet to operate even at the current scale. Since the internet has started the current explosion the standards and implementations have not been able to keep in pace with the new needs.

7.1 IPv6

The new and improved IP protocol version 6 has a larger address space than the version 4 IP. Even though the IP and TCP are two separate protocols, it is likely that IPv6 is going to have an affect on TCP protocol implementations. One reason for this is that TCP sockets have also the IP addresses, which are going to be altered in the new specification.

IPv6 does not require many changes to TCP protocol itself. The TCP header does not have any length field in the header and thus there is no limitation of the size of the TCP segments. However the Urgent Pointer cannot reference data beyond 65535 bytes. RFC 2147 tries to solve the Urgent Pointer problem [9]. This RFC is currently at a Proposed standard state.

7.2 Option bits

RFC 1323 specifies new option bits used in TCP header. That RFC is from year 1992 and it specifies two options for higher performance. One for window scale and the other for higher speed networks.

These new improvements have to be implemented both by internet servers and clients. For example Windows NT Server version 4.0 does not have window scale option [2].

8. CURRENT PROBLEMS WITH TCP

TCP was originally design to operate reliable over almost any transmission medium regardless of transmission rate, delay, corruption, duplication or reordering the segments. Since the protocol was first introduced transmission rates of networks have increased dramatically. Nevertheless TCP can work reasonable well over variety of Internet paths from slow rated dial-up modems even to the modern gigabit networks [7, 6]. However this kind of evolution in networks and also in lower level layers demands constant development of TCP.

Basically there are two main reasons for problems with TCP today. First, TCP tries to exceed the underlying network’s transport capacity, which causes congestion in the network and reduces connections’ data rates. Second, the traditional assumption of TCP is, that packet losses always indicates network congestion. This supposition is usually correct in wired networks but in wireless networks, where corrupted bit errors are common, it reduces data rates dramatically. Section 3 concentrates more about problems with TCP in wireless networks and also a few solutions are introduced (for instance the Snoop protocol).

There are also other complications with TCP and some of these are presented in next subsections.

8.1 TCP versus lower layer protocol’s congestion control

TCP runs well over networks, which have only a few features for congestion controlling and which provide no quality of service [7]. However, if the lower level layer provides congestion control function, problems arise because of also TCP provides congestion control and these two methods may not notice each other.

ATM is a good example of lower level protocol, which includes congestion controlling. If congestion occurs in the ATM switch, cells are beginning discarded. If the discarding is focused into individual cells rather than TCP segments, the receiver will receive many erroneous TCP segments and all of these segments must be retransmitted by the sender, which increases utilization of the network and decreases efficiency of the connection.

Figure 6: Performance of TCP over plain ATM (UBR)

Far better way for discarding individual cells, is to discard entire segments and allowing more entire segments to be passed through the switch. Figure 6 demonstrates performance of TCP over plain ATM, which discards individual cells [6] rather than entire TCP segments.

Some of the methods about selecting segments rather than cells to be discarded are introduced in the last section of this paper.

Another example of the lower level protocol, which provides congestion control is X.25 [10].

8.2 Quality of Service

Although TCP provides reliable transmission for applications, it does not guarantee the time within which segments are transmitted from the sender to the receiver. IP datagrams may also arrive in disorder into the receiver in TCP.

In other words, TCP does not offer constant transmission delay and therefore it does not match up with multimedia, audio or real-time applications [11].

8.3 Transactions

Distributed applications use often transaction-oriented communication. From the client’s point of view, a transaction is a sequence of operations that forms a single step, transforming the server data from one consistent state to the another [12]. One example of transaction may be a withdraw of $ 100 from account. Characters of transactions are atomicity, consistency, isolation and durability. Transactions are also short in the meaning of time.

Using TCP in client-server transactions arise two problems [13, 14]:

Although transactions are usually handled by remote procedure calls, a potential application of transaction-mode TCP (T/TCP) is SMTP. Using T/TCP could therefore significantly reduce the load on large mail hosts. Also Web browsers could use some of the advantages about T/TCP, since like transactions the most of Web traffic is typically short.

8.4 Asymmetry of the network

End-to-end performance of TCP may suffer due to network asymmetry, especially in the context of wide-area wireless network, since full bandwidth may not be achieved in unidirectional transfers because of the slow arrival of acknowledgments. Figure 7 illustrates an asymmetry network.

Figure 7: Network with asymmetry bandwidth

Examples of networks that exhibit asymmetry are wireless cable modem networks, Direct Broadcast Satellite (DBS) networks and Asymmetric Digital Subscriber Loop (ADSL) networks. One of the main reasons why interest is increased in asymmetry networks is again Web traffic, where substantially more data flows from the server to the client than vice versa.

9. TCP IMPLEMENTATION POLICIES

Although the TCP standard requires a precise specification of the protocol to be used between different hosts, there are several implementation policies for the designers of TCP [7]. Appendix 1 introduces TCP requirements summary [15].

9.1 Send policy

When PUSH flag is set on, the sender entity is free to transmit data as its own convenience. At the implementation point of view there is two alternative possibilities for sending TCP entity to do:

    1. Sends the data at once to the receiver, even if there is only little data in the segment to be delivered.
    2. Waits that a certain amount data to be accumulated and then sends the segment.

The first choice gives fast response times to the applications but there may occur a lot of overhead, since the ratio of header and data is high and there is also possibility of silly window syndrome. The second choice cuts down overhead in the terms of creating segment and sending it but on the other hand response times are not so quick than in the first policy.

9.2 Deliver policy

When the receiver gets segment with PUSH flag, there are again two possibilities for receiving entity to do:

    1. Delivers data directly to the upper layer.
    2. Buffers data and waits for more segments to arrive and then delivers a larger amount of the data into upper layer.

Again the first alternative gives better performance but it may require a lot of processing power and it may cause unwelcome number of interrupts.

9.3 Accept policy

The receiver must be aware that segments may be corrupted, duplicated or they have arrived from different paths of network, so segments may arrive in out of order. The simplest way for the receiver to receive a segment from the sender TCP entity, is to accept segment only if it is next in line and otherwise discard it. However this may demand a lot of retransmissions and decreases efficiency of the connection.

A better solution is to accept all segments that arrive within the certain receive window. This method requires more buffer space from the receiver and more complex algorithm but is usually implemented because of performance efficiency.

9.4 Retransmit policy

The sender TCP entity needs to store the segments, which are already sent but not yet acknowledged into a queue. There are three methods for handling this queue and it’s timer or timers:

    1. Sending TCP entity has one retransmission timer for the whole queue. When an acknowledgment arrives, acknowledged segments are removed from the queue and the timer is reset. If timer expires, then the first segment of the queue is transmitted and the timer is reset.
    2. Like the first one but when timer expires, the sender sends all segments and resets the timer.
    3. Each segment in the queue has it’s own timer and segments are handled individually. When segment is removed from queue, also the timer of removed segment must be deleted.

When the appropriate method is selected, also accept policy must be counted in and the right combination between these two policies quarantees efficiency of the retransmission operation.

9.5 Acknowledge policy

Since TCP is abided by positive acknowledgment policy, the receiver must acknowledge every incoming data segments. The receiver may acknowledge segment immediately, when data segment has arrived, which leads into increasing load on the network. Therefore the receiver usually does not acknowledge arriving data segments immediately, but records the need for acknowledgement and acknowledges many segments at the same time. Delay of the acknowledgement must not exceed a half of second [15] and if possible, the acknowledgement is binded into segment that contains also data.

9.6 Real implementations of TCP

9.6.1 TCP Reno

One of the most common implementation of TCP is known as TCP Reno, which was developed at the end of the last decade for the BSD 4.3 operating system [16]. TCP Reno contains following features:

There are also some modified version of TCP Reno, for example TCP New Reno [17], which has a few modifications to be done into Fast Retransmit and Fast Recovery phases.

9.6.2 TCP SACK

When multiple packets are lost from one send window of data, TCP may experience poor performance. A Selective Acknowledgment (SACK) [18] is a method, which can help to overcome this problem. With selective acknowledgment, the receiver may inform to the sender about all successfully arrived segments, so the sender needs to only retransmit the segments that really has been lost or corrupted.

Implementation of TCP SACK is based on TCP Reno, but it includes selective acknowledgment function. Simulation studies have showed that the strength TCP SACK over TCP Reno [18], but the negative aspect is that utilization of selective acknowledgment requires modifications to be done both on the sender and the receiver side.

10. WIRELESS TCP

TCP fits quite poorly into wireless networks, because it does not provide negative acknowledgment, which could easily be used for indicating bit errors in the arriving segments and because of TCP assumption, that every missing acknowledgment indicates network congestion. There are also other characteristics of wireless networks that must counted in when designing improvements into the communication protocol stack:

This section introduces a couple of methods, which are designed to improve performance of TCP over the wireless networks. Basically all of the used methods divide the connection between two end-to-end hosts into two different logical paths. TCP may be used normally at the wired part of the path and modifications are usually needed only into the wireless part of the network.

The main point in the wireless communications is that retransmissions should not be sended from the actual sender host, but the host next to the wireless part of transmission path. For example if host A is communicating with host B, then instead of host A should send retransmissions to host B, the base station may do it (figure 8). This method cuts down network’s utilization, improve efficiency of the communication and reduces processing load on host A.

Figure 8: A kind of wireless network

10.1 Snoop protocol

Snoop protocol [19] is a result of research at the University of California at Berkeley. Snoop protocol is a TCP-aware link layer protocol, which isolates wired senders from the characteristics of wireless network and it is meant to run, as an agent, primarily at the base stations of the wireless networks.

The Snoop agent monitors every TCP packets that passes trough the base station in either direction. The agent maintains cache of all TCP segments transmitted by fixed host. Figure 9 illustrates agent’s procedure when it receives data segment from the sender.

The buffered segment or segments are removed from base station after the wireless receiver has successfully acknowledgment segment or segments to the base station, which then forwards acknowledgment into the sender.

The Snoop agent detects the loss of packet or packets by:

Figure 9: The Snoop agent’s data segment handling

Figure 10: The Snoop agent’s acknowledgment handling

When the agent notices the loss of packets, it retransmits them into mobile host if previously lost segments are still stored in the cache (see figures 9 and 10).

If segments can not be located from cache then the original sender will anyhow eventually retransmit these segments. In addition, the base station hides the packet losses from the sender by not propagating duplicate acknowledgements and preventing unnecessary congestion control invocations at the source, which would otherwise to be result because of TCP’s fast retransmission function.

The simulations of the testing the Snoop protocol throughput performance in the real environment have shown that the Snoop protocol gives significant benefit over regular TCP connection (figure 11), achieving a bandwidth improvement factor of 2 to 20 depending on the bit error rate. In fact, the Snoop protocol was still robust and capable to run even when every other packet was being corrupted after last link, while regular TCP made no progress at all.

Figure 11: Throughput of the Snoop protocol

The testbed of figure’s 11 simulations consisted of Pentium PC base stations and IBM ThinkPad mobile hosts communicating over a 915 MHz AT&T Wawelan. All hosts were running BSD/OS 2.0 operating system. When packets were not lost, the wireless links were able to support about 1,5 Mbits per second out of rated maximum of 2 Mbits per second.

The Snoop protocol is a auspicious method for wireless networks not by only it’s effectiveness, but also because end-to-end communication remains as a normal TCP communication and the only modifications to communication protocol stack has to be done on the wireless base stations.

10.2 Indirect TCP

Indirect TCP (I-TCP) is another transmission protocol for wireless environment. I-TCP splits the TCP connection into two separate connections. The first connection goes from the sender to the base station and second one goes from the base station to the receiver. The base station just simply copies packets from other connection to the other. Both connections are now homogeneous, so the sender gets acknowledgments directly from the base station. There is also possibility of using other transport protocol than TCP in wireless part of the network.

The disadvantage of the I-TCP is that it violates the end-to-end semantics of TCP. On the other hand the congestion control algorithm will never be started unless there really is congestion in the wired part of the network.

10.3 Mowgli architecture

One example of I-TCP implementation is a Mowgli architecture, which is developed by the University of Helsinki together with some commercial companies like Nokia Telecommunications. The goal of the Mowgli is design and test data communication architecture for pan-European digital GSM-based mobile data service and to develop a prototype based on that architecture.

Mowgli architecture divides normal end-to-end TCP/IP connections into two parts. Normal TCP or UDP connections are used over wired network. Connections over wireless networks in Mowgli’s case over cellular telephone system are handled with non-TCP based protocol the Mowgli Data Channel Service (MDCS) [20]. The main idea in the Mowgli communication architecture is to replace the client-server paradigm with a client-mediator-server paradigm, where the real applications over the communication architecture do not aware existence of the mediator. The Mowgli is designed to offer high performance over low bandwidth, ability to recover from unexpected short disconnections and also to tolerance for long and highly variable delays, which all are typical characters of GSM. Figure 12 exhibits the architecture of the Mowgli [21].

 

Figure 12: Architecture of the Mowgli

The implementation of the architecture is divided into three logical layers:

Data channels can be opened as stream mode providing TCP-like functionality or as message channels if datagram service is desired. However, unlike UDP delivering messages is reliable between mobile-connection host and mobile workstation.

The MDCS supports up to 256 simultaneous data channels, which are all independently flow controlled. The Mowgli data channel protocol (MDCP) always tricks to transmit data at the best possible speed, which the wireless link is capable of. Today maximum data speed at GSM network is 9 600 bits per second but this is about to be change into 14 400 bits per second. The experiments of using Mowgli in GSM network instead of traditional TCP in wireless part of network have given very promising results [20], indicating that the actual data transfer capacity may be even as high as 85 percent of the theoretical maximum available capacity.

11. TCP OVER ATM

Since TCP/IP is the most common data communication protocol nowadays, it is natural that bringing ATM networks into Internet, the later ones must accommodate themselves with existing TCP implementations. Figure 13 demonstrates a modern approach in which two existing local area networks are connected into together by using ATM as a backbone.

Figure 13: A network topology with two Ethernet networks and ATM backbone

When using TCP over ATM, there are in practice two different service classes of ATM to be chosen: unspecified bit rate (UBR) and available bit rate (ABR) [7, 22]. The performance of TCP over ATM is usually measured with two factors:

Both the efficiency and the fairness must be counted in equally when designing improvements into TCP over plain UBR.

11.1 TCP over UBR

As mentioned earlier TCP over the plain UBR gives a poor performance over the end-to-end TCP connection. The main reason for this deficient efficiency is the UBR’s minimal congestion control, which just drops overflowed cells [22]. When running TCP on the plain UBR also the following effects can be detected [7]:

By using larger buffers in ATM switches and choosing effective switch dropping policy the performance may be improved noteworthily.

      1. Partial packet discard policy
      2. When the partial packet discard (PPD) policy notices congestion appearing at the ATM switch and IP datagram’s cell is dropped from switch buffer, are then all the subsequent cells of that packet also been discarded. The beginning of the next TCP segment can be located by searching ATM cell header with the service data unit (SDU) bit on, which indicates the end of AAL5 protocol data unit (PDU).

      3. Early packet discard policy

The partial packet discard policy discards approximately half of the cells (the tail of the datagram) of the one TCP segment. A better performance can be achieved if all cells of a TCP segment are discarded.

Early packet discard (EPD) policy keeps tracking on a switch buffer queue’s size. If a certain threshold is achieved, although there is actually not yet need for discarding any cells, is then a whole higher layer protocol data unit discarded. Early packet discard policy is further divided into [22]:

Figure 14 introduces efficiencies of the partial packet discard policy and the early packet discard policy. In the early packet discard policy the threshold is set to be a half of the total buffer size [7].

Figure 14: Performance of TCP over UBR with the switch dropping policies

      1. Selective packet dropping policy
      2. Using early packet discard policy with TCP congestion controlling provides almost as good efficiency as TCP over non-ATM network but it does not provide adequate fairness for the different connections, since EPD selects the first available entire TCP segment to be discarded. There are several studies that exhibit EDP to be unfair for different TCP connections [7]. For example early packet discard policy favours connections that uses larger TCP segment size, since when a segment is to be discarded, probability to find a small segment is higher than to find a large segment.

        A further improvement into TCP segment dropping policy is selective packet dropping policy (SPD) [22]. The main idea of SPD is that it keeps track of the activity of each virtual channels (VC) by counting the number of cells from each VC at the ATM switch buffer. A fair allocation is calculated as the current buffer occupancy divided by number of active virtual channels and the load ratio is then computed for each VC. If the load ratio of the virtual channel exceeds a certain threshold, are the new packets of VC discarded on the switch. Simulations have showed that using selective packet dropping policy improves the fairness of TCP over UBR with the early packet discard policy.

      3. Early packet discard policy with fair buffer allocation

An alternative method to guarantee the fairness of early packet discard policy is called fair buffer allocation (FBA). When congestion happens, the fair buffer allocation policy chooses TCP segments from the virtual channel that is using more than a fair amount of the ATM switch’s buffer space to be deleted [7]. Figure 15 demonstrates an algorithm used by fair buffer allocation. In the algorithm Q is the number of cells in the entire switch buffer, Qj is the number of cells in the number of cells in the virtual channel j and K is a control parameter with a typical value between 1 and 2.

Simulations of EDP with fair buffer allocation policy indicates slightly efficiency over EDP with selective packet dropping policy in the both means of throughput and fairness [7]. Both FBA and SPD provide consequence improvement over plain UBR and EPD, especially in the local area networks. In the wide area network however early packet discard policy alone quarantees adequate throughput and fairness.

Figure 15: Fair buffer allocation algorithm

11.2 TCP over ABR

Although there are available methods for achieving good fairness and throughput in TCP over UBR, the UBR service is not scalable in terms of increasing the number of TCP sources [23]. TCP over available bit rate (ABR) offers better scalability but on the other hand it is far more complex to design and implement than TCP over UBR. Some of the reasons why TCP over ABR is much more difficult to design are [7, 23]:

The throughput and the fairness of TCP over ABR does not provide consequence improvement to the much simpler implementations of TCP over UBR [7], so TCP connections are usually handled over at the unspecified bit rate service class of ATM.

11.3 Conclusion

It is obvious that the current expansion requires changes in standards. The new improved features may require changes to the current systems.

From the end user’s point of view, many of the technical improvements may seem as contradiction to improvement. If the systems cannot meet the promised improvements many of the new systems are seen as way of getting more money from the user. The user does not care as long as his personal connection to Web functions adequately. This adequate operation may be far from optimal operation, but the user is not prepared to pay the premium price of properly functioning network.

Whether the new features are implemented using by standard methods or quick fixes to keep the network alive remains to be seen. The need for higher speed, more effective data throughput and wireless solutions are the most important questions of todays networks also in the level of transport protocols. Much of research is done to develop TCP to be appropriate also in those areas, but there is no one happy agreement yet how this can be done.

      1. Appendix 1

FOOTNOTES:

  1. "ALP" means Application-Layer program.

 

A. References

[1] J. Postel, Internet Protocol - DARPA Internet Program Protocol Specification, RFC 791, USC/Information Sciences Institute, 1981

[2] MSDN, Microsoft Developer Network, 1995

[3] S. Karanjit, Inside TCP/IP: Third ed., New Riders, Indiana, 1997

[4] J. Postel, Transmission Control Protocol, RFC 793, California, 1981

[5] Teleware, TCP/IP-tekniikat, Helsinki, 1998

[6] V. Jacobson etc., TCP Extensions for High Performance, RFC 1323, 1992

[7] W. Stallings, High-Speed networks: TCP/IP and ATM design principles, chapter 10, Prentice Hall, 1998

[8] J. Stevens, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, RFC 2001, 1997

[9] D. Borman, TCP and UDP over IPv6 Jumbograms, RFC 2147, 1997

[10] http://www-nmimc.med.navy.mil/crconsolidation/Technical%20Info/defs. htm, 1998

[11] T. Connolly etc., An Extension to TCP: Partial Order Service, RFC 1693, 1994

[12] G. Coulouris etc., Distributed Systems: concepts and design, chapter 6, Addison-Wesley, 2nd edition, 1995

[13] R. W. Stevens, TCP/IP Illustrated, Volume 3, Addison-Wesley, 1996

[14] R. Braden, Extending TCP for Transactions – Consepts, RFC 1379, 1992

[15] R. Braden, Requirements for Internet Hosts – Communication Layers, RFC 1122, 1989

[16] P. Ranne, TCP:n kehitys vuosina 1988 – 1997, Internet protocols seminar paper, University of Helsinki, 1997

[17] http://www.spartan.net/~ccharala/sat_res_pres.pdf, 1998

[18] M. Mathis etc., TCP Selective Acknowledgment Options, RFC 2018, 1996

[19] http://www.cs.berkeley.edu/~ss/papers/allerton/html/allerton.html, 1997

[20] Kiiskinen J. etc., Data Channel Service for Wireless Telephone Links, University of Helsinki, Series of Publications C, No. C-1996-1, 1996

[21] http://www.cs.helsinki.fi/~helaaman/Mowgli/sld004.htm, 1998

[22] http://www.cis.ohio-state.edu/~jain/cis788-97/tcp_over_atm/, 1998

[23] S. Kalyanaraman etc., Performance of TCP/IP over ABR Service on ATM Networks, Proc. IEEE Globecom ’96, p. 468 – 475, 1996