There are modifications that most TCP implementation deploys. The first concerns the length of the timeout interval after a timer expiration. In this modification, whenever the timeout event occurs, TCP retransmits the not-yet-acknowledged segment with the smallest sequence number, but each time TCP retransmits, it sets the timeout interval to twice the previous value. However, whenever the timer is started after either of the two other events (ACK or data replication), the timeout interval is derived from the most recent values of EstimatedRTT and DevRTT.

All details about TCP timer can be found in the Official Documentation. This page shows how this actually works (you can find Excel source here).

Reliable Data Transfer

NextSeqNum = InitialSeqNum;
SendBase   = InitialSeqNum;

loop( forever ){
   switch( event ){
      event: data received from application above
         create TCP segment with sequence number NextSeqNum
         if( timer currently not running )
            start timer
         pass segment to IP
         NextSeqNum = nextSeqNum + length(data)
         break;
      event: timer timeout
         retransmit not-yet-acknowledged segment with smallest sequence number
         start timer
         break;
      event: ACK received, with ACK value AckNum
         if( AckNum > SendBase ){
            SendBase = AckNum
            if( there are currently any not-yet-acknowledged segmenta )
               start timer
         }
         break;
   }
}

TCP ACK Generation recommendation

Event	TCP Receiver Action
Arrival of in-order segment with expected sequence number. All data up to expected sequence number already acknowledged.	Delayed ACK. Wait for 500ms for arrival of another in-order segment. If next in-order segment does not arrive in this interval, send an ACK
Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK transmission.	Immediately send single cumulative ACK, ACKing both in-order segments.
Arrival of out-of-order segment with higher-than-expected sequence number.	Immediately send duplicate ACK, indicating sequence number of the next expected byte (which is the lower end of the gap).
Arrival of a segment that partially or completely fills gap in received data.	Immediately send ACK, provided that segment starts at the lower end of the gap.

Fast Retransmit version:

NextSeqNum = InitialSeqNum;
SendBase   = InitialSeqNum;

loop( forever ){
   switch( event ){
      event: data received from application above
         create TCP segment with sequence number NextSeqNum
         if( timer currently not running )
            start timer
         pass segment to IP
         NextSeqNum = nextSeqNum + length(data)
         break;
      event: timer timeout
         retransmit not-yet-acknowledged segment with smallest sequence number
         start timer
         break;
      event: ACK received, with ACK value AckNum
         if( AckNum > SendBase ){
            SendBase = AckNum
            if( there are currently any not-yet-acknowledged segmenta )
               start timer
         }
         else{ /* a duplicate ACK for already acknowledged segment */
            increment number of duplicate ACKs received for AckNum
            if( number of duplicate ACKs received for AckNum == 3 ){
               /* TCP fast retransmission */
               resend segment with sequence number AckNum
            }
         }
         break;
   }
}

Flow control

• TCP doesn't specify what has to be done with out-of-order segments. This is left to the programmers implementing a particular version. One of the options is store such packets in a buffer.
• Relationship between Application layer and Transport layer (TCP in our case) is pull relations, that is, application layer can request the next portion of received data from TCP, but TCP cannot push the data up.
• Thus, we come to the idea of window size the total amount of bytes the receiver can buffer.
• TCP can take care of a situation when sender sends data abd receiver is not able to buffer it because its buffer is full and the upper level doesn't request the next portion of data. To prevent sender from sanding more data in such situations each TCP segment contains an additional portion of information in it - receiver window size that contains the amount of bytes of the receiver is yet able to store in the buffer.
• On the Kurose-Ross web page there is a Java applet illustrating how it works.
• The sender can determine if it may to send the next portion by comparing the receiver window and the difference between the last byte sent and the last byte ACKed. If the receiver window is small, then the sender can slow down the speed it's sending segments. If the receiver window is zero, then TCP requires the sender to send 1-byte of data segments just to keep receiving information about the window size.

TCP Connection Management

Establishing connection

• Step 1. The client-side TCP randomly chooses the ClientNextSeqNumber and sends a TCP segment that contains:
  • port numbers (client and server)
  • ClientNextSeqNumber
  • zero as ACK number
  • bit flag SYN set to 1
• Step 2. Once the server-side gets a request for conenction it allocates TCP buffers and variables, randomly chooses its own ServerNextSeqNum and send back a segment containing:
  • port numbers (client and server)
  • ServerNextSeqNumber
  • ClientNextSeqNumber + 1 as ACK number
  • bit flags SYN and ACK set to 1
• Step 3. Upon receiving the connection-granted segment, the client also allocates buffers and variables to the connection. The client host then sends the server yet another segment containing:
  • port numbers (client and server)
  • ClientNextSeqNumber + 1
  • ServerNextSeqNumber + 1 as ACK number
  • bit flags SYN=0 and ACK=1
  • this segment may already contain data

Q: How are the sequence numbers chosen?
A: In most Berkley-derived implementations, when system is initialized the initial sequence number is set to 1. It then incremented by 64,000 every half-second, and will cycle back to 0 about every 9.5 hours. Additionally, each time a connection is established, this variable is incremented by 64,000.

Terminating connection normally

1. One side sends a segment with FIN=1
2. The other side replies with a usual TCP acknowledgment segment and also sends another TCP segment with FIN=1
3. The side initiated the termination sends usual TCP ACK segment to finally terminate the connection

Aborting a connection

1. any queued data is thrown away and the reset segment is sent immediately
2. the receiver of the RST can tell that the other end did an abort instead of normal close

TCP Options

• the end of the option list,
• no operation,
• and the maximum segment size.

Please refer to RFC 793 for additional information.