Connection Establishment in TCP

• Identifying a TCP Connection
  • TCP connection:

    • A TCP connection is a logical connection between 2 communicating entities. Packets from each TCP connection are uniquely identified by 4 values: The Source IP-Address The Source TCP port number The Destination IP-Address The Destination TCP port number           Graphically: (Source-IP-Addr, SourcePort#, Dest-IP-Addr, DestPort#)

    ---

  • A TCP connection is uni-directional

    But most TCP connections will have a reverse connection where the source identifiers and destination identifiers are reverse

    (I.e., you usually create two uni-directional TCP conections --- because very few applications are send-only applications)

  • Each TCP connection has a state (because it needs to ensure reliability).

  ---

  ---

• The state of a TCP connection
  • Each TCP connection has a state

    (We say that TCP is state-full

  • The TCP state information consists of:

    • The current sequence number of the sliding window the current acknowledgement number of the sliding window

    ---

  • NOTE:

    • In contrast, the UDP protocol is a stateless protocol

    ---

    ---

  • Consequence of state-fullness of TCP:

    • The state of a TCP connection is lossed when a computer crashes There is no way to recover the old state of a TCP connection Consequently: TCP connections are resetted when the source or receiver crashes (The reset could take some time to perform, because TCP uses time out to detect failure)

  • NOTE:

    • In contrast, when one of the sender or receiver using the UDP protocol, crashes, the communication can continue after the crashed machine has been rebooted !!! This can be done thanks to the stateless nature of UDP

  ---

  ---

  ---

  ---

• Establishing a TCP Connection
  • Establishing TCP connection is:

    • Making sure that sender's state and the receiver's state are consistent I.e., the send sequence number is equal to the receive sequence number

  • Fact:

    • Before a sender and a receiver can exchange data through TCP, they must first establish a TCP connection. The purpose of the TCP connection establishment procedure is to establish a consistent initial state between the Sending TCP and the receiving TCP. (i.e., the initial sequence number and ACK number between the sender and receiver must be equal !

  ---

  ---

• What's the fuss: Why can't TCP just use ZERO (0) as initial number ???
  • The natural inclination is to ask:

    • Why can't TCP sender/receiver use a fixed agreed initial sequence number (e.g., ZERO)

  • Short answer:

    • Because TCP operates in a very hostile environment where messages can be delayed for a prolonged period of time. Certain errors in such an environment can compromise TCP's ability to provide reliability when a fixed initial state is used at connection establishment

    ---

  • Long answer by example:

    • Suppose 2 programs P1 and P2 always establish a TCP connection using initial sequence number equal to 0: P1 sends the first message, but it was delay (congestion): P1 times out and retransmit the first message. In the mean time, the first transmission is still delayed (due congestion): The retransmitted packet was routed over speedier route (because routing tables were updated) from P1 to P2 After the delivery, the TCP connection is then terminated (closed). (The first transmission is still delayed due to congestion): Now...., another program P3 makes a TCP connection to a program P4 And it happens that P3 and P4 use the same source and destination ports used by P1 and P2 At this moment, the delayed packet from P1 to P2 arrives: Result: The bogus message will be accepted for delivery ny P4 !!! This is wrong and TCP will fail to guarantee reliability...

    ---

  • Note:

    • If the second TCP connection was using a different starting send number, the stale packet would not have been accepted !

  ---

  ---

  ---

  ---

• Minimizing the probability of communication error in TCP
  • Reducing the likelihood of accepting a bogus packet:

    • Every new TCP connection must pick a different starting send sequence number TCP has a initial connection establishment phase, where each both end points must select a random sequence number The connection establishment phase will make sure that sender and receiver agree on the initial sequence numbers

  ---

  ---

• Control fields used in connection establishment
  • Meaning of the control fields used in TCP connection establishment:

    • SYN flag bit: indicates that the other TCP module must synchronize its ACK number (receive sequence number) to the sequence number in SeqNo field of TCP segment ACK flag bit: indicates that ACK number in TCP segment is valid RST flag bit: Reset - purge the state information belonging to this TCP connection (The TCP connection is identified by (Src IP#, Src Port#, Dest IP#, Dest Port#)) SeqNo: sequence number ACK number : ACK number

  ---

  ---

• Nomenclature
  • The names given to the processes that establishes a TCP connection comes historically from the client/server computation model:

  • The initiator of a TCP connection is traditionally called a client

  • The receiver of a TCP connection request is traditionally a server that services the requests made by the clients

  ---

  ---

  ---

  ---

• TCP Connection Establishment procedure
  • Remember that a TCP connection is identified by:

    • (srcIP, srcPort#, destIP, destPort#)

    What this means is:

    • The control messages in the example only applies to the TCP connection with the given (srcIP, srcPort#, destIP, destPort#) !!!

    ---

  • The sequence of messages exchanged to establish a TCP connection is as follows:

    • Client (initiator) picks a random (send) sequence number and sends it inside a SYN (synchronization) message The ACK bit of this message is reset (meaning that the ACK number is invalid) Example: This message requests that the receiver (server) creates a TCP connection with the ACK number (receive sequence number) equal to 7625 When the server (receiver) receives the SYN (synchronization) with seq. no 7625 , it does the following: Set the ACK number (receive sequence number) to 7626 Note: not 7625 !!!! it sends back an acknowledgement with ACK 7626 !!! Because: Remember that in TCP that ACK(n) acknowledges all data with send sequence numbers that are < n !!! Also, a typical TCP connection is bi-directional (because the server must send data back to the client reliably) The receiver (server) will also picks a random (send) sequence number for its TCP connection The receiver (server) will send its own TCP connection request in a SYN (synchronization) message - the SYN request can be piggypacked inside the ACK message Example: This message serves 2 purposes: it acknowledges to the client that it's sequence number is correctly recorded. it requests the receiver (the client) to synchronize the ACK number for a new TCP connection from the server (so the server can send messages reliably to the client). When the server's reply is received by the client, the following will take place: The ACK indication (with SeqNo 7626) in the message will cause the client to increase its send sequence number to 7626 The SYN request (with seq. no. 1234) in the message will cause the client to: Set the ACK number (receive sequence number) to 1235 Note: not 1234 !!!! it sends back an acknowledgement with ACK 1235 !!! Example: Finally, when the server (receiver) receives the ACK (only) message, it advances its send sequence number (slides window forward) to 1235 Example: You can see that the client and servercorrect send and ACK numbers of each other !!!

  ---

  ---

  ---

  • NOTE:

    • ALWAYS Remember that ACK(n) in TCP acknowledges all data with sequence numbers < n

    ---

  • Three-way handshake

    • The above procedure is called three-way handshake (because it uses 3 messages).

  ---

  ---

  ---

  ---

  Examples to illustrate how the establishment protocol of TCP overcome some interesting errors

  ---

  ---

  • Just to give you a taste of how  robust the connection establishment protocol really is, I will give you a number of error conditions that the designers of TCP has thought about solving...

    Note in these examples the use of the RESET flag, which make a TCP protocol remove the state information of a connection.

  ---

  ---

• TCP Connection Establishment Example 1: processing a new connection request
  • Qeustion: Suppose a server receives a new connection request:

    • Is this connection request     (identified by     (srcIP, srcPort#, destIP, destPort#))     always valid ?

    ---

    ---

  • Case 1: the connection request is valid

    A connection request will normally be valid:

    • Here, the client computer wants to establish a TCP connection and it picks the random number 7625

      The client sends a TCP connection request with Seq no 7625 to the server.

    ---

  • Case 2: bogus TCP connection request

    A "new" connection request can also be bogus as illustrated in the following sequence of events:

    • The client computer picks the random number 7625 and sends a valid connection request to the server. However, the connection request message was delayed: The client computer times out and ... retransmits the connection request to the server. The retransmission was routed on a speedier path: The client computer made the connection, finishes sending its messages and disconnects. All the while, the delayed connection request has not yet arrived (messages in the Internet can be delayed for many seconds; some data transfers take less than a second to complete) And after the connection has been terminated, the delayed connection request finally arrives: Clearly, this connection request is bogus

    ---

    ---

  • How should the server behave ?
    • Fact:

      • BOTH case are identical from the point of view of the server I.e.: the server r eceives a new connection request The server cannot tell (smell) the difference !!!

    • Options for the server:

      • Accept the connection request      or Consequence: Server may have accepted a  bogus request Reject the connection request Consequence: Server will  never accept  any legitimate request Obviously, the reject option is unacceptable !!!!

    • Therefore, the server accept the TCP connection request (in good faith)

      The server will reply with an ACK message and also request its own TCP connection (to prepare to reply to client's requests)

      Example:

    ---

    ---

  • How should the client behave ?

    • The 2 different cases are resolved by the client Only the client has sufficient information to resolve these 2 cases !!!!

    Client's behavior in case 1:

    • In case 1, the client sends a real connection request (Remember that a TCP connection request is identified by (srcIP, srcPort#, destIP, destPort#)) Therefore, the client has created some TCP state information belonging to the TCP connection (srcIP, srcPort#, destIP, destPort#)) When the server's reply arrives, the client can find the TCP state information for the reply message: Since the sequence number (7626) in server's reply Acknowledges the client's outstanding connection request (7625) , the client accepts the ACK message and sends back an ACK for the server's connection request:

    ---

    ---

  • The client's behavior in case 2:

    • In the second case, the client does not have any record for the TCP connection (srcIP, srcPort#, destIP, destPort#) When the server's reply arrives, we have the following situation: Notice that in the message, the ACK bit is SET . That means that the server is telling the client: "your data upto sequence number 7626 are received". In other words: Hey, client, you better update your sequence number !!! But the client does not have any state information for such a TCP connection !!! Therefore, the client will send a RESET message, telling the server to purge the state information associated with the TCP connection: When the server receives the RESET message, it removes the state information on the connection.

  ---

  ---

  ---

  ---

• TCP Connection Establishment Example 2: a new connection request arrives while an old connection exists
  • Scenario:

    Suppose a pair of computers (one client and one server) has already established a TCP connection :

    And a connection request with the same (srcIP, srcPort#, destIP, destPort#) arrives, but with a different sequence number:

    ---

    ---

    Question:

    • Is this connection request invalid ?

    Answer:

    • Not sure... The server cannot tell with 100% certainty if this connection request is bogus or legitimate

    I will show this fact with the following 2 sceanrios...

    ---

    ---

  • Case 1: the connection request can be valid if:

    • the client has crashed (So the TCP state is lossed) And when the client recovered, it wants to re-establish a new TCP connection (using the same port numbers)

    ---

  • Case 2: the connection request can also be bogus

    One possible cause it was a delayed connection request:

    • The client computer picks the random number 7625 and sends a connection request to the server But the request was delayed: The client computer times out and retransmits a connection request to the server. Furthermore, the retransmission was routed on a speedier path: The client and server completes the TCP connection: (In the mean time, the delayed connection request has not yet arrived) The client sends 30 bytes of data (will move the window): The server sends the ACK for the data: Notice that the ACK Nnumber (receive sequence number) in server is changed (The receive window has slided !) When the client receives the ACK message it will update its send sequence number : Notice that the Sequence Number in client is changed (The send window has slided !) BTW, we are now in the same state as the qesution: At this moment, the delayed connection request arrives: Clearly, in this scenario, the connection request is bogus (invalid)

    ---

    ---

  • Conclusion:

    • Even when the server has an on-going TCP connection, it cannot tell if a "new" connection request is valid or bogus !!!

    ---

    ---

  • How should the server behave ?
    • Fact:

      • Again, BOTH case are identical from the point of view of the server I.e.: the server receives a new connection request The server cannot tell (smell) the difference !!!

    • Options for the server:

      • Accept the connection request      or Consequence: Server will  lose a  legitimate TCP connection !! The accept option is unacceptable !!!! Reject the connection request Consequence: Server will  never accept  any legitimate request The reject option is also unacceptable !!!!

      Looks like there is no way out :-(

      ---

    • Solution:

      • Check with the client !!!

      Notice that the server has a TCP connection and the TCP connection is state-full

      The server can use the state information to double check (confirm) with the client by sending it an empty data TCP packet:

      NOTE:

      • In the mean time, the connection request is pending The server will wait until the reply (ACK) for the empty data TCP segment is received before processing the pending connection request

    ---

    ---

  • How should the client behave ?

    • Again, the 2 different cases are resolved by the client Because only the client has differentiating information to resolve these 2 cases.

    Client's behavior in case 1:

    • In the first case, the client did indeed send a real connection request and therefore, the client contains TCP state information of the TCP connection: When the server's reply arrives, we have the following situation: The client detects that the ACK number in the reply does not match with its sequence number !!! The client will therefore reject. the empty data message by sending a RESET message: Notice that the RESET message contains a sequence number !!!! The sequence number in a RESET message can be used to distinguish different pending requests When the server receives the RESET(7656) message, it deletes the TCP state information for the corresponding TCP connection. Then the server proceeds to process the pending connection request message: (We assume that the server picked the random number 5678 to make its (reverse) TCP connection) When the client receives the server's reply, it can check that the reply indeed acknowledges its outstanding connection request, and responds with an ACK: Result: after the  client recovers from a failure, the  new TCP connection has been  established successfully

    ---

    ---

  • Client's behavior in case 2:

    • In the second case, the client has the empty data message arrives: The client receives the empty data message Since the sequence number in packet matches the expected sequence number, the empty data message will be accepted by the client (I.e., it is deemed kosher) The empty TCP message does not require an ACK message The server receives ACK messageno response and will retry a few times: The retransmissions will not trigger any replies from the receiver After a maximum number of retries, the server will purge the bogus connection request: The connection proceeds uninterrupted....

  ---

  ---

  ---

  ---

  State Transition Diagrams

  ---

• What is a state transistion diagram
  • Communication protocols are often described formally with a state transistion diagram.

  • The state transistion diagram consists of:

    • Nodes that represent states Edges that represent transistions

    The nodes and edges in a state transistion diagram is in fact a finite state automata

    ---

  • Example state transition diagram:

    ---

  • The edges contains labels of the form:

    • action/event -------------------- response

    Notes:

    • The action or event indicates the actions/events that triggers the associated transition I.e., when the indicated action/event occurs while TCP is in that state, the state will transition to the next state given by that edge The response associated with the edge denote what TCP will do when that transition takes effect.

    ---

  • Reading a state transition diagram:

    How to read the diagram:

    • While in state 1, if event A happens (e.g., receive some mossage), then the protocol will Issue the response B Make the state transition to state 2 On the other hand, while in state 1, if the action C happens (e.g., user program issues a disconnect command), then the protocol will Issue the response C Make the state transition to state 3

  ---

  ---

  ---

  ---

• State transition diagram for TCP connection establishment
  • The following state transition diagram exposes the message interchange in TCP in relationship with the TCP system calls:

  • How to read the TCP transistion state diagram:

    • The left portion of the diagram is for the "server" The right portion of the diagram is for the "client" Begin the client and the server in the CLOSED state The UNIX "listen()" system call (extern action by the program) will trigger the external action Passive open This event will cause the TCP protocol at the server to enter into the Listen state: This transistion does not trigger any response.... When a client program wants to make a TCP connection, the client program will invoke the UNIX system call "connect()" The corresponding (external) event is called active open: This transition will cause a response of transmitting a SYN message to the server The client TCP protocol enters into the SYN_Sent state. When the SYN message is received by the server TCP protocol, it causes the responses of sending a SYN+ACK message to the client: The server TCP protocol to enter the SYN_Recv state. When the SYN+ACK message is received by the client TCP protocol, it causes the response of sending a ACK message to the server: The client to enter in the EXSTABLISH state (client is done !) While in the EXSTABLISH state, the TCP protocol will send and receive data messages. Finally, when the ACK message is received by the server TCP protocol, it causes the server TCP module to enter in the EXSTABLISH state: Now the server can also send data messages to the client...

    Reference: http://www.mathcs.emory.edu/~cheung/Courses/455/Syllabus/7-transport/tcp-connect.html