TCP MAIN FEATURES AND BEHAVIOUR AUTHOR NIR SHAFRIR

TCP MAIN FEATURES AND BEHAVIOUR AUTHOR: NIR SHAFRIR + Bits 0 - 3 4 -9 0 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) Data BASED ON THE FOLLOWING RESOURCES: The TCP/IP Guide - (http: //www. TCPIPGuide. com) Version 3. 0 - Version Date: September 20, 2005 tcp-parameters page on (http: //www. iana. org/assignments/tcp-parameters) RFC 793 - Transmission Control Protocol - (http: //www. faqs. org/rfcs/rfc 793. html) RFC 1323 / RFC 2018 / RFC 1072 / RFC 1693 / RFC 1644 / RFC 1146 / RFC 2385 - (http: //www. faqs. org/rfcs) Wikipedia, the free encyclopedia – (http: //en. wikipedia. org/wiki/Transmission_Control_Protocol)

TCP Data Stream Processing and Segment Packaging

Operation Of An Unreliable Protocol

Basic Reliability: Positive Acknowledgment With Retransmission (PAR) This diagram shows one of the most common simple techniques for ensuring reliability. Each time a message is sent by Device A, it starts a timer. Device B sends an acknowledgment back to A when it receives a message so A know it was successfully transmitted. If a message is lost, the timer goes off and A retransmits the data. Note that only one message can be outstanding at any time, making this system rather slow.

Enhanced Positive Acknowledgment With Retransmission (PAR) This diagram shows two enhancements to the basic PAR scheme. First, each message now has an identification number; each can be acknowledged individually, so more than one can be in transit at a given time. Second, device B regularly communicates to A a send limit parameter, which restricts the number of messages A can have outstanding at once. B can adjust this parameter to control the flow of data from A.

Conceptual Division of the TCP Transmission Stream Into Categories Bytes Sent And Acknowledged: The earliest bytes in the stream will have been sent and acknowledged. These are basically “accomplished” from the standpoint of the device sending data. For example, let's suppose that 31 bytes of data have already been send acknowledged. These would fall into Category #1. Bytes Sent But Not Yet Acknowledged: These are the bytes that the device has sent but for which it has not yet received an acknowledgment. The sender cannot consider these “accomplished” until they are acknowledged. Let's say there are 14 bytes here, in Category #2. Bytes Not Yet Sent For Which Recipient Is Ready: These are bytes that have not yet been sent, but which the recipient has room for based on its most recent communication to the sender of how many bytes it is willing to handle at once. The sender will try to send these immediately (subject to certain algorithmic restrictions we'll explore later). Suppose there are 6 bytes in Category #3. Bytes Not Yet Sent For Which Recipient Is Not Ready: These are the bytes further “down the stream” which the sender is not yet allowed to send because the receiver is not ready. There are 44 bytes in Category #4.

TCP Transmission Stream Categories and Send Window Terminology The Send Window and Usable Window The key to the operation of the entire process is the number of bytes that the recipient is allowing the transmitter to have unacknowledged at one time. This is called the send window, or often, just the window. The window is what determines how many bytes the sender is allowed to transmit, and is equal to the sum of the number of bytes in Category #2 and Category #3. Thus, the dividing line between the last two categories (bytes not sent that recipient is ready for and ones it is not ready for) is determined by adding the window to the byte number of the first unacknowledged byte in the stream. In our example above, the first unacknowledged byte is #32. The total window size is 20.

Processing Acknowledgments and Sliding the Send Window When the sending device receives this acknowledgment, it will be able to transfer some of the bytes from Category #2 to Category #1, since they have now been acknowledged. When it does so, something interesting will happen. Since five bytes have been acknowledged, and the window size didn't change, the sender is allowed to send five more bytes. In effect, the window shifts, or slides, over to the right in the timeline. At the same time five bytes move from Category #2 to Category #1, five bytes move from Category #4 to Category #3, creating a new usable window for subsequent transmission. So, after receipt of the acknowledgment, the groups will look like this

TCP “Three-Way Handshake” Connection Establishment Procedure This diagram illustrates how a conventional connection is established between a client and server, showing the three messages sent during the process and how each device transitions from the CLOSED state through intermediate states until the session is ESTABLISHED. TCP Simultaneous Open Connection Establishment Procedure This diagram shows what happens when two devices try to open a connection to each other at the same time. In this case instead of a three-way handshake, each sends a SYN and receives an ACK. They each follow the same sequence of states, which differs from both sequences in the normal three-way handshake.

TCP Connection Termination Procedure (Normal / Simultaneous) This diagram shows the conventional termination procedure for a TCP session, with one device initiating termination and the other responding. In this case the client initiates; it sends a FIN which is acknowledged by the server. The server waits for the server process to be ready to close and then sends its FIN, which is acknowledged by the client. The client waits for a period of time to ensure that its ACK is received, before proceeding to the CLOSED state. Under certain circumstances both devices may decide to terminate a connection simultaneously, or nearly simultaneously. In this case each sends a FIN and before getting an ACK for it, receives the other device’s FIN. Each acknowledges the other’s FIN and waits for a period of time before closing the connection. Note the transition through the CLOSING state, which is only used as part of simultaneous termination

THE TCP PACKET DESCRIPTION + Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) Data

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Source Port: 16 bits The source port number. Padding (to 32) Data

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Destination Port: 16 bits The destination port number. Padding (to 32) Data

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Padding (to 32) Data Sequence Number: 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.

Sequence Number: 32 bits (cont. ) A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. This mechanism allows for straight-forward duplicate detection in the presence of retransmission. 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. It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 2^32 - 1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2^32.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G A C K R S T S Y N F I N Checksum 160 192 P S H Window Urgent Pointer Options (optional) Options (cont. ) 224 Padding (to 32) Data Acknowledgment Number: 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.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) 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.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Reserved: 6 bits Reserved for future use. Must be zero. Padding (to 32) Data

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Padding (to 32) Data Control Bits: 6 bits (from left to right): URG: Urgent Pointer field significant Acknowledgment field significant Function connection sequence numbers from sender ACK: PSH: Push RST: Reset the SYN: Synchronize FIN: No more data

Control Bits: 6 bits (cont. ): URG: A control bit (urgent), occupying no sequence space, used to indicate that the receiving user should be notified to do urgent processing as long as there is data to be consumed with sequence numbers less than the value indicated in the urgent pointer. ACK: A control bit (acknowledge) occupying no sequence space, which indicates that the acknowledgment field of this segment specifies the next sequence number the sender of this segment is expecting to receive, hence acknowledging receipt of all previous sequence numbers. PSH: A control bit (push) occupying no sequence space, indicating that this segment contains data that must be pushed through to the receiving user. RST: A control bit (reset), occupying no sequence space, indicating that the receiver should delete the connection without further interaction. The receiver can determine, based on the sequence number and acknowledgment fields of the incoming segment, whether it should honor the reset command or ignore it. In no case does receipt of a segment containing RST give rise to a RST in response.

Control Bits: 6 bits (cont. ): SYN: A control bit in the incoming segment, occupying one sequence number, used at the initiation of a connection, to indicate where the sequence numbering will start. FIN: A control bit (finis) occupying one sequence number, which indicates that the sender will send no more data or control occupying sequence space.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) Data Window: 16 bits The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) Data Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Padding (to 32) Data Checksum: 16 bits (cont. ) The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP.

+ Bits 0 - 3 4 -9 0 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset Reserved 128 U R G P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) 224 Padding (to 32) Data Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) Data Options: variable Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option: Case 1: A single octet of option-kind. Case 2: An octet of option-kind, an octet of option-length, and the actual optiondata octets.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 128 Data Offset Reserved U R G A C K P S H S Y N F I N Checksum 160 192 R S T Window Urgent Pointer Options (optional) Options (cont. ) 224 Padding (to 32) Data Options: variable (cont. ) The option-length counts the two octets of option-kind and option-length as well as the option-data octets. Note that the list of options may be shorter than the data offset field might imply. The content of the header beyond the End -of-Option option must be header padding (i. e. , zero). A TCP must implement all options.

Options: variable (cont. ) Kind Length Meaning 0 - End of option list. 1 - No-Operation. 2 4 Maximum Segment Size. Specific Option Definitions: End of Option List 0000 Kind=0 This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset field. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the TCP header. No-Operation 00000001 Kind=1 This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary.

Options: variable (cont. ) Maximum Segment Size: Kind=2 Length=4 000000100 max seg size (cont. ) Maximum Segment Size Option Data: 16 bits If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request (i. e. , in segments with the SYN control bit set). If this option is not used, any segment size is allowed. These are the original options. The aditional options are listed and discribed here.

+ Bits 0 - 3 0 4 -9 10 - 15 16 - 31 Source Port Destination Port 32 Sequence Number 64 Acknowledgement Number Flags 96 Data Offset 128 Reserved U R G 224 P S H R S T S Y N F I N Checksum 160 192 A C K Window Urgent Pointer Options (optional) Options (cont. ) Padding (to 32) Data Padding: variable 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.

TCP MAIN FEATURES AND BEHAVIOUR THE END

FULL TCP OPTIONS LIST Kind Length Meaning 0 - End of option list. [RFC 793] 13 1 - No-Operation. [RFC 793] 14 3 TCP Alternate Checksum Request [RFC 1146] 2 4 Maximum Segment Size. [RFC 793] 15 N TCP Alternate Checksum Data [RFC 1146] 3 3 WSOPT - Window Scale [RFC 1323 ] 16 Skeeter [Knowles] 4 2 SACK Permitted [RFC 2018 ] 17 Bubba [Knowles] 5 N SACK[RFC 2018 ] 18 3 Trailer Checksum Option [Subbu & Monroe] 6 6 Echo (obsoleted by option 8) [RFC 1072 ] 19 18 MD 5 Signature Option [RFC 2385] 7 6 Echo Reply (obsoleted by option 8) [RFC 1072 ] 20 SCPS Capabilities [Scott] 8 10 TSOPT - Time Stamp Option [RFC 1323 ] 21 Selective Negative Acknowledgements [Scott] 9 2 Partial Order Connection Permitted [RFC 1693 ] 22 Record Boundaries [Scott] 10 3 Partial Order Service Profile[RFC 1693 ] 23 Corruption experienced [Scott] 11 CC [RFC 1644 ] 24 SNAP [Sukonnik] 12 CC. NEW [RFC 1644 ] 25 Unassigned (released 12/18/00) 26 TCP Compression Filter [Bellovin] CC. ECHO [RFC 1644]

FULL TCP OPTIONS LIST (cont. ) TCP Window Scale Option (WSopt): Kind=3 Length=3 bytes 00000011 Shift. cnt This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift. cnt' bits for transmission in SEG. WND. The value 'shift. cnt' may be zero (offering to scale, while applying a scale factor of 1 to the receive window). This option may be sent in an initial <SYN> segment (i. e. , a segment with the SYN bit on and the ACK bit off). It may also be sent in a <SYN, ACK> segment, but only if a Window Scale op- tion was received in the initial <SYN> segment. A Window Scale option in a segment without a SYN bit should be ignored. The Window field in a SYN (i. e. , a <SYN> or <SYN, ACK>) segment itself is never scaled. Sack-Permitted Option: Kind=4 Length=2 00000100 00000010 This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the SACK option once the connection has opened. It MUST NOT be sent on non-SYN segments. TCP Sack-Permitted TCP SACK Option: Kind=5 Length=Variable The SACK option is to be sent by a data receiver to inform the data sender of non-contiguous blocks of data that have been received and queued. The data receiver awaits the receipt of data (perhaps by means of retransmissions) to fill the gaps in sequence space between received blocks. When missing segments are received, the data receiver acknowledges the data normally by advancing the left window edge in the Acknowledgement Number Field of the TCP header. The SACK option does not change the meaning of the Acknowledgement Number field. This option contains a list of some of the blocks of contiguous sequence space occupied by data that has been received and queued within the window.

FULL TCP OPTIONS LIST (cont. ) TCP Echo Option: Kind=6 Length=6 00000110 4 bytes of info to be echoed . . This option carries four bytes of information that the receiving TCP may send back in a subsequent TCP Echo Reply option (see below). A TCP may send the TCP Echo option in any segment, but only if a TCP Echo option was received in a SYN segment for the connection. When the TCP echo option is used for RTT measurement, it will be included in data segments, and the four information bytes will define the time at which the data segment was transmitted in any format convenient to the sender. TCP Echo Reply Option: Kind=7 Length=6 00000111 00000110 4 bytes of echoed info . . A TCP that receives a TCP Echo option containing four information bytes will return these same bytes in a TCP Echo Reply option. This TCP Echo Reply option must be returned in the next segment (e. g. , an ACK segment) that is sent. If more than one Echo option is received before a reply segment is sent, the TCP must choose only one of the options to echo, ignoring the others; specifically, it must choose the newest segment with the oldest sequence number. To use the TCP Echo and Echo Reply options, a TCP must send a TCP Echo option in its own SYN segment and receive a TCP Echo option in a SYN segment from the other TCP. A TCP that does not implement the TCP Echo or Echo Reply options must simply ignore any TCP Echo options it receives. However, a TCP should not receive one of these options in a non-SYN segment unless it included a TCP Echo option in its own SYN segment. TCP Timestamps Option (TSopt): Kind=8 Length=10 00001000 00001010 TS Value (TSval) . . . TS Echo Reply (TSecr) The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option. The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a times- tamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; A TCP may send the Timestamps option (TSopt) in an initial <SYN> segment (i. e. , segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it re- ceived a TSopt in the initial <SYN> segment for the connection. . . .

FULL TCP OPTIONS LIST (cont. ) TCP POC-permitted Option: Kind=9 Length= 2 00001001 00000010 TCP POC-service-profile Option: Kind=10 Length=3 00001010 00000011 Start_flag (1 bit) | End_flag (1 bit) | Filler (6 bit) CC Option: Kind=11 Length=6 00001011 00000110 Connection Count: SEG. CC . . . This option may be sent in an initial SYN segment, and it may be sent in other segments if a CC or CC. NEW option has been received for this incarnation of the connection. Its SEG. CC value is the TCB. CCsend value from the sender's TCB. CC. NEW Option Kind: 12 Length: 6 00001100 00000110 Connection Count: SEG. CC . . . This option may be sent instead of a CC option in an initial <SYN> segment (i. e. , SYN but not ACK bit), to indicate that the SEG. CC value may not be larger than the previous value. Its SEG. CC value is the TCB. CCsend value from the sender's TCB. CC. ECHO Option Kind: 13 Length: 6 00001101 00000110 Connection Count: SEG. CC . . . This option must be sent (in addition to a CC option) in a segment containing both a SYN and an ACK bit, if the initial SYN segment contained a CC or CC. NEW option. Its SEG. CC value is the SEG. CC value from the initial SYN. A CC. ECHO option should be sent only in a <SYN, ACK> segment and should be ignored if it is received in any other segment.

FULL TCP OPTIONS LIST (cont. ) TCP Alternate Checksum Request Option: Kind=14 Length=3 00001110 00000011 chksum Here chksum is a number identifying the type of checksum to be used. The currently defined values of chksum are: 0 -- TCP checksum 1 -- 8 -bit Fletcher's algorithm 2 - 16 -bit Fletcher's algorithm 3 -Redundant Checksum Avoidance [Kay] TCP Alternate Checksum Data Option: Kind=15 Length=N 00001111 N DATA . . . DATA This field is used only when the alternate checksum that is negotiated is longer than 16 bits. These checksums will not fit in the checksum field of the TCP header and thus at least part of them must be put in an option. Whether the checksum is split between the checksum field in the TCP header and the option or the entire checksum is placed in the option is determined on a checksum by checksum basis.