Outline

• transmission control protocol
• header
• sequence and acknowledgment numbers
• TCP timer
• header flags
• connection establishment and shutdown
• flow control window

Reminder: summary of retransmission components

• checksum is used to ensure packet integrity
• timer is used to decide when to retransmit a packet
• sequence number is used to determine correct packet re-ordering, duplication, and loss
• acknowledgement is a packet used to inform the sender of packet receipt
• negative acknowledgement is a packet used to inform the sender that an expected packet was not received
• window is the amount of outstanding unacknowledged data a sender may have. Once the whole window is sent, the sender must stop
• flow control is the slowing down of a sender to achieve specific goals, e.g., avoid sending more data than a receiver has buffer space

Transmission Control Protocol

• like UDP, TCP provides demultiplexing and data integrity (checksum)
• in addition, TCP provides a number of services:
  • reliable, in-sequence data transmission
  • connection-oriented data exchange
  • "stream of octets" model
  • slowing down the sender to:
    • prevent network congestion (congestion control)
    • prevent receiver buffer overflow (flow control)
  • urgent pointers, to allow a receiver to skip over less-relevant data
• a TCP segment consists of a TCP header, followed by zero or more bytes of TCP data

TCP header

• the basics of TCP are defined in RFC 793:

   0                   1                   2                   3   
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Source Port          |       Destination Port        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Sequence Number                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Acknowledgment Number                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Data |       |C|E|U|A|P|R|S|F|                               |
  | Offset|Resrved|W|C|R|C|S|S|Y|I|            Window             |
  |       |       |R|E|G|K|H|T|N|N|                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           Checksum            |         Urgent Pointer        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Options                    |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             data                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

  (the header shown here also reflects RFC 3168)
• the header is typically 20 bytes long, but may be longer if options are present
• the header length field ("Data Offset") is the number of 32-bit words in the header, so takes the value 5 for 20-byte headers
• source port, destination port, and checksum are the same as for UDP
• since IP reports packet length, no header length field is provided in the TCP header

TCP sequence number

• the TCP sequence number is 32 bits long
• the most significant byte of the number is sent first
• TCP sequence numbers count bytes rather than packets
• the sequence number in the header is the sequence number of the first byte in the data
• if there is no data, the sequence number is still set to the sequence number of the next byte that could be sent
• since a TCP connection is bidirectional, a different initial sequence number (ISN) is used in each direction: each peer picks the ISN it will use in sending data

TCP acknowledgement number

• the TCP ack field reports the sequence number of the next byte that is expected
• this byte may have already been sent
• a single packet may carry data and acknowledgement, and we refer to it as a data packet, or
• a single packet may carry an acknowledgement but no data: this is an ack packet
• the ack field must be set correctly every time the ack bit is set in the header, which is for all packets except the very first packet sent on a connection

TCP sequence numbers example

• suppose host L sends a packet to host R with sequence number 983 and 100 bytes of data
• host R should send back a packet with ack number 1083
• this packet could be an ack (no data), or the ack could be piggybacked with a data segment

• to expand the above example, suppose L sends two packets, with sequence numbers 983 and 1083, the first with 100 bytes of data, the second with one byte of data
• host R can send two acks, 1083 and 1084, or could send a single ack with ack number 1084
• becaus TCP acks are cumulative, the second ack is sufficient
• for this reason, TCP often delays acknowledging a single segment, waiting for a short time before sending the ack: delayed acknowledgement
• when using delayed acks, TCP should ack at least once every two segments

TCP retransmission

• suppose a packet or an ack is lost
• a lost ack might not be a big deal if a later ack confirms receipt of the same data
• but when receiving a packet out of order, the receiver must keep acknowledging the last in-order packet received
• the receiver normally buffers data received out of order
• in any case, the TCP sender has to keep a timer
• when the timer expires, the first unacknowledged TCP segment is retransmitted
• data originally sent as multiple segments smaller than the Maximum Segment Size (MSS) may be coalesced together and retransmitted as one segment

setting timers

• if packets are only retransmitted very rarely, timer settings are not crucial
• using a long-period (slow) timer, packets are only retransmitted when needed, reducing the additional data sent
• using a fast period timer, packets are retransmitted as quickly as possible, reducing the time before the receiver gets all its data
• timers can be set adaptively, based on the observed RTT of the connection, that is, the time from sending a packet (that is never retransmitted) to getting the ack for that packet

TCP timer

• TCP measures the time from sending packet x to receiving the corresponding Ack: RTT_x
• on each measurement, TCP updates a running average: corresponding Ack: RTT_ave = (1-alpha) RTT_ave + alpha RTT_x
• typically, alpha = 1/8, which is easy to compute with binary arithmetic
• the average (estimated) RTT tracks the last few RTT_x, with more weight given to the most recent
• on each measurement, TCP also updates a running average of the difference between the estimated RTT and the measurement: Diff_ave = (1-beta)Diff_ave - beta |RTT_x - RTT_ave|
• typically, beta = 1/4
• the timer is set to expire after time RTT_ave + 4 Diff_ave
• this value provides retransmission as soon as possible on predictable networks, and gives a good margin for highly variable networks
• the TCP timer should be running whenever there are outstanding unacknowledged segments

TCP timer details

• each time a packet is lost, the timer is doubled: binary exponential backoff
• RTT_ave and Diff_ave are then used again once the data is flowing without error
• packets that are retransmitted are not used to compute RTT_x
• TCP interprets multiple duplicate acks as a sign that the receiver has out-of-order data, and immediately (without waiting for the timer) retransmits the next packet after the last one that is being acknowledged: fast retransmit

TCP header flags

• the 8 TCP header flags and their meanings are:
  1. CWR, Congestion Window Reduced
  2. ECE, Explicit Congestion Notification
  3. URG, the segment contains urgent data, and the urgent pointer marks its location
  4. ACK, the acknowledgement field is valid
  5. PSH, the data should be delivered (PuSHed) to the application promptly
  6. RST, ReSeT the connection
  7. SYN, this is the first packet in a new connection
  8. FIN, this is the last packet in an existing connection, I promise never to send data again on this connection
• every packet but the first has the ACK bit set
• the first packet in each direction has the SYN bit set
• no new data may be sent after sending a FIN packet, though data can still be received, acknowledged, or retransmitted

TCP connection establishment

• to start a connection, the client sends a SYN packet to the server
• the server looks up the destination port number, and if a server is listening on that port, returns a packet with both the SYN and the ACK bits set (SYN+ACK)
• this SYN+ACK packet has the ISN of the server, and also carries the received sequence number + 1
• that means the SYN bit is counted in the sequence number space, just as if it was a byte of data
• the client replies to the SYN+ACK with an ACK packet, also increasing its own sequence number and the acknowledgement number
• the ACK packet may carry data, but often doesn't
• altogether, this exchange of three packets to set up the connection is known as the three-way handshake

TCP connection setup results

• at the end of the three-way handshake each side has:
• knowledge that the peer is interested in setting up a connection (assuming the three-way handshake is successful)
• the sequence number expected for the first byte of data that the peer will send
• the window size, reporting the maximum amount of data that may be sent
• possibly a number of options, where the peer has told us how they are going to use TCP or how they would like us to use TCP
• for example, window scaling may tell us to multiply the window value by a certain power of two
• if the peer does not have an application listening on a given port, instead of a SYN+ACK it sends a segment that has the RST bit, to reset the connection

TCP connection shutdown

• once a TCP host knows it will never send data again on a connection, perhaps because the application closed the connection, it can set a packet with the FIN bit set
• the receiving application acknowledges the FIN, again incrementing the ack number as if the FIN bit was a byte of data
• the connection is now half-closed: only one side may send data
• the remaining side may send a FIN when it is ready to completely close the connection
• this FIN is also acked

a very simple TCP example

• host L sends to R a SYN packet with sequence number 99, ack number 0, source port 1000, destination port 2000
• host R sends to L a SYN+ACK packet with sequence number 555, ack number 100, source port 2000, destination port 1000
• port numbers and the ACK bit will not be shown in the remainder of this example, as every packet has the ACK bit set, and the port numbers are always 1000->2000 for packets from L to R, and 2000->1000 for packets from R to L
• L sends to R a packet with sequence number 100, ack number 556
• L sends to R a packet with sequence number 100, ack number 556, and one byte of data
• R sends to L a packet with sequence number 556, ack number 101, and two bytes of data
• L sends to R a packet with sequence number 101, ack number 558
• R sends to L a FIN packet with sequence number 558, ack number 101,
• L sends to R a packet with sequence number 101, ack number 559
• L sends to R a FIN packet with sequence number 101, ack number 559
• R sends to L a packet with sequence number 559, ack number 102,

TCP state machine (RFC 793)

                              +---------+ ---------\      active OPEN  
                              |  CLOSED |            \    -----------  
                              +---------+<---------\   \   create TCB  
                                |     ^              \   \  snd SYN    
                   passive OPEN |     |   CLOSE        \   \           
                   ------------ |     | ----------       \   \         
                    create TCB  |     | delete TCB         \   \       
                                V     |                      \   \     
                              +---------+            CLOSE    |    \   
                              |  LISTEN |          ---------- |     |  
                              +---------+          delete TCB |     |  
                   rcv SYN      |     |     SEND              |     |  
                  -----------   |     |    -------            |     V  
 +---------+      snd SYN,ACK  /       \   snd SYN          +---------+
 |         |<-----------------           ------------------>|         |
 |   SYN   |                    rcv SYN                     |   SYN   |
 |   RCVD  |<-----------------------------------------------|   SENT  |
 |         |                    snd ACK                     |         |
 |         |------------------           -------------------|         |
 +---------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +---------+
   |           --------------   |     |   -----------                  
   |                  x         |     |     snd ACK                    
   |                            V     V                                
   |  CLOSE                   +---------+                              
   | -------                  |  ESTAB  |                              
   | snd FIN                  +---------+                              
   |                   CLOSE    |     |    rcv FIN                     
   V                  -------   |     |    -------                     
 +---------+          snd FIN  /       \   snd ACK          +---------+
 |  FIN    |<-----------------           ------------------>|  CLOSE  |
 | WAIT-1  |------------------                              |   WAIT  |
 +---------+          rcv FIN  \                            +---------+
   | rcv ACK of FIN   -------   |                            CLOSE  |  
   | --------------   snd ACK   |                           ------- |  
   V        x                   V                           snd FIN V  
 +---------+                  +---------+                   +---------+
 |FINWAIT-2|                  | CLOSING |                   | LAST-ACK|
 +---------+                  +---------+                   +---------+
   |                rcv ACK of FIN |                 rcv ACK of FIN |  
   |  rcv FIN       -------------- |    Timeout=2MSL -------------- |  
   |  -------              x       V    ------------        x       V  
    \ snd ACK                 +---------+delete TCB         +---------+
     ------------------------>|TIME WAIT|------------------>| CLOSED  |
                              +---------+                   +---------+

                      TCP Connection State Diagram

TCP connection state

• The state of the connection must be recorded on each peer (the two peers may be in different states)
• other variables, including the window, the expected sequence number, the last acknowledged sequence number, etc, must also be recorded on each peer
• each peer maintains a record (in C, a struct) to keep track of the per-connection variables: the Transmission Control Block or TCB
• The TCB is created with the socket, and deleted when the socket is closed
• in a SYN-flooding attack, the attacker sends lots of SYN packets, attempting to fill all TCPs on the target with information that will never be used
• the SYN-cookie defense does not allocate a TCP until the third packet is received: instead the sequence number encodes, in a way that is difficult to guess, the information in the SYN
• the attacker now must either send SYN packets with correct (non-spoofed) IP addresses, or never see the SYN+ACK and therefore be unable to send a correct ACK that will indeed reserve the TCB

TCP flow control

• like the sequence and ack numbers, the TCP window counts bytes
• if window scaling is in effect, the window counts in units of 2, 4, 8, 16, or in general, 2ⁿ bytes
• the window states how many unacknowledged bytes a sender may have
• the receiver sends a window to the sender to reflect the amount of free buffer space it has
• this is known as flow control: since the sender can send at most one window's worth of data every RTT, the receiver can slow down the sender by sending a small window

TCP buffering

• a TCP sender must buffer data to be sent until the window allows it to actually be sent
• if the application sends more data than TCP can buffer, the application should be suspended, or the send operation should return an error
• a TCP sender must also buffer data that has been sent, until the receiver acknowledges it

• a TCP receiver must buffer data received but not yet consumed by the application
• a TCP receiver should also buffer data received out of order, but still in the window
• the TCP receiver should send to the sender a window that is no larger than the amount of data it can buffer for that connection

zero window issues

• once the sender has filled the receiver's buffer, the receiver should ack all the data, but send a zero window
• once the application consumes the data, the receiver should send a new ack packet to "open" the window
• however, the ack may be lost
• for this reason, a sender with data to send should periodically send the first byte of data to the receiver even if the window is zero
• the receiver need not accept this byte of data -- if it really has no room, it may re-acknowledge the previous byte instead
• in any case, the acknowledgement will carry the current window