Transmission Control Protocol Simulator
(Slow Start)

Protocol Description

TCP (Transmission Control Protocol) is a connection-oriented protocol for transferring data reliably in either direction between a pair of users. TCP is a rather complex protocol, so it is easy to lose track of the simulation. Try not to do anything too complicated! There are client-server and peer-peer simulations as alternatives that illustrate opening and closing connections.

This simulation focuses on dynamic window management - specifically what is called "slow start". This is designed to avoid the protocol flooding the network with packets when it starts, and to ensure that the protocol recovers slowly following message loss and timeout due to congestion.

Users simply send messages of a fixed size; the content of messages is not identified. The medium maximum packet size is the protocol segment size. Depending on this, messages may be sent as a number of fragments. Data transfer is also subject to the current window size of the receiver, and may be held up if the receiver's window becomes full.

When data arrives, it is not immediately delivered to the receiving user. Instead, data is accumulated and can be delivered later ("Deliver octets to user"). If the receiving window becomes full, new requests to send data will be buffered. When the receiving window opens again, this buffered data can be sent ("Send octets to peer").

Messages may contain a send sequence number (the offset of where the message starts in the user's octet stream), an acknowledgement sequence number (the offset of the next octet expected), and the current window (how many octets can be received).

Slow start is governed by two protocol variables: cwind (congestion window) and ssthresh (slow start threshold). These are measured in octets for this simulation, but are sometimes counted as numbers of segments. (Multiply the number of segments by the segment size to get the number of octets.) The slow start procedure operates as follows:

Initial Phase

The minimum of the congestion window size and the receiver window size determines how much data can be sent. The protocol starts conservatively with cwind set to the segment size. As each acknowledgement arrives, cwind is increased by the segment size. The amount of data that can be sent thus typically doubles in each round-trip time (i.e. the time to send a message and get a response). The amount is ultimately limited by the receiver's window. The available window thus increases exponentially (shown as "exp." in the simulation when cwind is increased).

Congestion Action

When a timeout occurs and the protocol has to retransmit, the congestion window is set back to one segment size. At this point, the threshold ssthresh is set to half the previous value of cwind. Suppose that the segment size is 200, so that cwind starts at 200. On subsequent acknowledgements, cwind could rise to 1600. If congestion causes loss at this point, cwind will be set back to 200 and ssthresh will be set to 800 (half of 1600).

Congestion Recovery

Now the window is built up exponentially again. Once it reaches ssthresh, it is no longer increased so aggressively. Instead, cwind increases by one segment size for each round-trip time. This is irrespective of how many acknowledgements arrive during this period, unlike the exponential phase where every acknowledgement causes the window to double per round trip time. During the recovery phase, the available window increases linearly (shown as "lin." in the simulation). The window will then become 900, 1000, etc. up to the receiver maximum. If congestion again causes loss, the procedure is repeated.

Because the simulation does not run in real time, it does not reflect round-trip times. As a result, its behaviour during the exponential and linear phases appears similar. However, the phase is indicated depending on whether cwind is below or above the threshold.

TCP is rather complex, so the simulation does not attempt to faithfully reflect all its details. Although the main paths should work as expected, it may be possible to get the simulation into unusual states in which it does not behave correctly.

Things the simulation does not cover include the following. See advanced guides to TCP for more information.

• advanced congestion control
• handling duplicate acknowledgements
• fast retransmit
• fast recovery

Protocol Parameters

The following settings are adequate for a simple simulation. For a more advanced exploration, choose different options and click Change Settings. This may cause the simulation to restart.

Protocol Simulation

The protocol simulation shows a time-sequence diagram with two peer service users, protocol entities that support them, and a communications medium (network) that carries messages. The connection phase is not shown in this simulation as it is assumed to have just occurred. Equally, the disconnection phase is not shown.

Up one level to Protocol Simulators