TCP Error Recovery

To accomplish reliability, TCP numbers data bytes using the Sequence and Acknowledgment fields in the TCP header. Here you can see a web server is sending 1000 bytes of data to web browser and a sequence number 1000 is used in the TCP header. The web server sends another 1000 bytes of data with sequence number 2000 and yet another 1000 bytes of data with sequence number 3000. Next the web browser is sending acknowledgement to the server for successfully receiving of 3000 bytes. The 4000 in the acknowledgement field implies the next byte to be received.

TCP was designed to recover from node or line failures where the network propagates routing table changes to all router nodes. Since the update takes some time, TCP is slow to initiate recovery. The TCP algorithms are not tuned to optimally handle packet loss due to traffic congestion. Instead, the traditional Internet response to traffic problems has been to increase the speed of lines and equipment in order to say ahead of growth in demand.

TCP treats the data as a stream of bytes. It logically assigns a sequence number to each byte. The TCP packet has a header that says, in effect, "This packet starts with byte 379642 and contains 200 bytes of data." The receiver can detect missing or incorrectly sequenced packets. TCP acknowledges data that has been received and retransmits data that has been lost. The TCP design means that error recovery is done end-to-end between the Client and Server machine. There is no formal standard for tracking problems in the middle of the network, though each network has adopted some ad hoc tools.

TCP Flow Control

TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate. For example, if a PC sends data to a smartphone that is slowly processing received data, the smartphone must regulate the data flow so as not to be overwhelmed.

TCP uses a sliding window flow control protocol. In each TCP segment, the receiver specifies in the receive window field the amount of additionally received data (in bytes) that it is willing to buffer for the connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host.
TCP sequence numbers and receive windows behave very much like a clock. The receive window shifts each time the receiver receives and acknowledges a new segment of data. Once it runs out of sequence numbers, the sequence number loops back to 0.

When a receiver advertises a window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from a deadlock situation that could arise if a subsequent window size update from the receiver is lost, and the sender cannot send more data until receiving a new window size update from the receiver. When the persist timer expires, the TCP sender attempts recovery by sending a small packet so that the receiver responds by sending another acknowledgement containing the new window size.

If a receiver is processing incoming data in small increments, it may repeatedly advertise a small receive window. This is referred to as the silly window syndrome, since it is inefficient to send only a few bytes of data in a TCP segment, given the relatively large overhead of the TCP header. TCP senders and receivers typically employ flow control logic to specifically avoid repeatedly sending small segments.

An image for TCP sequence numbers and receive windows behave very much like a clock. The receive window shifts each time the receiver receives and acknowledges a new segment of data. Once it runs out of sequence numbers, the sequence number loops back to 0.

Another illistration for flow control -

TCP does not perform any routing because it relies on it's lower layer IP/Network layer to perform all the routing. However, because IP does not guarantee end to end delivery it relies on TCP for error recovery and flow control.

Multiplexing is done by both TCP and UDP for deciding on how to deliver information to the appropriate computer. This is done using ports in the TCP Header field. Let's look at this scenario:

Computer 1 wants a web page from server 2 so it sends the request to it. What first happens is Computer 1 picks a random port to send the data from to the server. We all know that Port 80 is the destination port for the majority of all web pages so that never changes. Let's say that Compuer 1 chooses port 6789 to send from. Now, what we hvae just created here is a "socket" which is essentially just data inside the TCP header field used for mutliplexing.

Now Server 2 sees this information and uses the TCP header to form the "socket" which includes; IP address, transport Protocol and Port #. Sockets are used both ways because the server must send data back to the client, thus the server will create a socket. Lets examine what each socket looks like: (We use Fake IP addresses here for example)
Computer 1 (Sending data to the server): 10.0.0.1 - TCP - 80

That socket is used for sending data to the server; however, also remember that there is more information contained in the TCP header such as the source port from the originating computer (Computer 1). Now Sever 2 needs to send data back to that single Computer 1 (let's imagine that 100 other computers are connected to Server 2 as well) and to accomplish this it looks at the TCP header for the Port # and IP address and sends the data back to Computer 1 with this information. Although the way that the server tells how to send is with the unique port number used because you can have two computers in a remote LAN use the same IP address assigned to that subnet. Let's examine that socket:

Server 2 (Sending data back to Computer 1): 63.0.0.1 - TCP - 6789

The IP of Server 2 is 63.0.0.1 and it's using TCP as the transport layer protocol and sending the data back to Computer 1 on port 6789.

TCP also performs error recovery using sequence and acknowledgement fields in the TCP header. Each data byte (or segment) is numbered as a "Sequence" number when sent to a remote PC requesting it. Typically, the sequence number reflects the number of the first byte in the segment; however, this could also just be a random number so don't worry about this. You can actually setup a test environment with a client and a server and tun a program like Wireshare or tcpdump to examine a single transmission between a client and a server.

So lets assume that a client is sending data to a web server again:

Server 2 sends (3) 100 byte segments to Computer 1 (We will see later why it is only 3 100 byte segments and not 8 or 20). Once the server has sent those ordered bytes it awaits for a "Forward Ackniwledgement" from the client. The expected response should look like:

NO DATA - Acknowledgement=400

This indicates that the client recieved order bytes 100-300 and is expecting the next segment ordered 400. Let's assume that only ordered segments 100 and 300 were sent to Computer 1. The client recognizes that it doesn't have 200 and send a forward acknowledgement that looks like this;

NO DATA - Acknowledgement=300

Now the server knows that it didn't receive 200 so it resends that ordered segment and then the client responds;

NO DATA - Acknowledgement=400

Now the server knows it received ordered pairs 100-300 and to send the next ordered segments to the client. The sending server (Server 2) sets an "Acknowledgement time out" period where it waits a random time for a response and if that expires it resends ALL the data back to Computer 1.

TCP Data Segmentation

Segmentation is the process of carving up information into smaller pieces. The documentation for Transmission Control Protocol (TCP) refrers to what it calls 'data streams'. A data stream is really nothing more than a series of zeroes and ones that represent information. TCP receives data from an application and segments the data into pieces. This segmentation is necessary so that the information can be placed inside the TCP data field.

Once the data is segmented it is encapsulated within TCP. The TCP segment and TCP header is then passed down to Internet Protocol which stuffs the TCP segment and header into the payload of the IP datagram.

By segmenting the data, TCP creates chunks of data that can be routed separately over whatever connections are needed in order to reach the destination. Any of these segments can be retransmitted to replace the original segmentst that got lost or damaged in transmission.

TCP Reassembly

TCP reassembles segments into a data stream and feeds that data stream to the application. The best known example of this activity is HTTP transfer of a web page. The web server loads a web page from disk, encapsulates the web page text in HTTP headers, the passes the HTTP encoded stream of text to TCP. TCP segments the text stream for transport across the network. The networking software (the stack) receives the TCP data segments and reassembles the HTTP stream of text, which your web browser reads, and renders as a web page.

TCP segment structure
Transmission Control Protocol accepts data from a data stream, segments it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated into an Internet Protocol (IP) datagram. A TCP segment is "the packet of information that TCP uses to exchange data with its peers."

The term TCP packet, though sometimes informally used, is not in line with current terminology, where segment refers to the TCP PDU, datagram to the IP PDU and frame to the data link layer PDU:

A TCP segment consists of a segment header and a data section. The TCP header contains 10 mandatory fields, and an optional extension field (Options, orange background in table).

The data section follows the header. Its contents are the payload data carried for the application. The length of the data section is not specified in the TCP segment header. It can be calculated by subtracting the combined length of the TCP header and the encapsulating IP header from the total IP datagram length (specified in the IP header).

TCP Header

• Source port (16 bits) – identifies the sending port
• Destination port (16 bits) – identifies the receiving port
• Sequence number (32 bits) – has a dual role:
• If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.
• If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.
• Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.
• Data offset (4 bits) – specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.
• Reserved (3 bits) – for future use and should be set to zero
• Flags (9 bits) (aka Control bits) – contains 9 1-bit flags
• NS (1 bit) – ECN-nonce concealment protection (added to header by RFC 3540).
• CWR (1 bit) – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).
• ECE (1 bit) – ECN-Echo indicates
• If the SYN flag is set (1), that the TCP peer is ECN capable.
• If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168).
• URG (1 bit) – indicates that the Urgent pointer field is significant
• ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
• PSH (1 bit) – Push function. Asks to push the buffered data to the receiving application.
• RST (1 bit) – Reset the connection
• SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags change meaning based on this flag, and some are only valid for when it is set, and others when it is clear.
• FIN (1 bit) – No more data from sender
• Window size (16 bits) – the size of the receive window, which specifies the number of bytes (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive.
• Checksum (16 bits) – The 16-bit checksum field is used for error-checking of the header and data
• Urgent pointer (16 bits) – if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
• Options (Variable 0–320 bits, divisible by 32) – The length of this field is determined by the data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option, and is the only field that is not optional. Depending on what kind of option we are dealing with, the next two fields may be set: the Option-Length field indicates the total length of the option, and the Option-Data field contains the value of the option, if applicable. For example, an Option-Kind byte of 0x01 indicates that this is a No-Op option used only for padding, and does not have an Option-Length or Option-Data byte following it. An Option-Kind byte of 0 is the End Of Options option, and is also only one byte. An Option-Kind byte of 0x02 indicates that this is the Maximum Segment Size option, and will be followed by a byte specifying the length of the MSS field (should be 0x04). Note that this length is the total length of the given options field, including Option-Kind and Option-Length bytes. So while the MSS value is typically expressed in two bytes, the length of the field will be 4 bytes (+2 bytes of kind and length). In short, an MSS option field with a value of 0x05B4 will show up as (0x02 0x04 0x05B4) in the TCP options section.
• Padding – The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros.
• Some options may only be sent when SYN is set; they are indicated below as . Option-Kind and standard lengths given as (Option-Kind,Option-Length).
• 0 (8 bits) – End of options list
• 1 (8 bits) – No operation (NOP, Padding) This may be used to align option fields on 32-bit boundaries for better performance.
• 2,4,SS (32 bits) – Maximum segment size
• 3,3,S (24 bits) – Window scale
• 4,2 (16 bits) – Selective Acknowledgement permitted.
• 5,N,BBBB,EEEE,... (variable bits, N is either 10, 18, 26, or 34)- Selective ACKnowledgement (SACK)These first two bytes are followed by a list of 1–4 blocks being selectively acknowledged, specified as 32-bit begin/end pointers.
• 8,10,TTTT,EEEE (80 bits)- Timestamp and echo of previous timestamp
• 14,3,S (24 bits) – TCP Alternate Checksum Request.
• 15,N,... (variable bits) – TCP Alternate Checksum Data.

    (The remaining options are obsolete, experimental, not yet standardized, or unassigned)