TCP

   

Is a Transport Layer Protocol. Is a process-to-process Protocol. Uses flow control & error control mechanism. Is called a connection-oriented, reliable transport protocol.

TCP Services
   

Stream Delivery Service Full-Duplex Communication Connection-Oriented Service Reliable Service

Full-Duplex Communication
TCP offers full-duplex service, where data can flow in both directions at same time.  Each TCP has a sending & receiving buffer & segments move in both directions.  Connection oriented service : - When a process at site A wants to send & receive data from another process at site B, the following occurs : - Two TCPs establish a connection between them. - Data are exchanged in both directions. - Connection is terminated. Connection is a virtual connection.


Stream Delivery Service

 

Tcp is a stream-oriented protocol. It allows sending process to deliver data as a stream of bytes & allows receiving process to obtain data as a stream of bytes. TCP creates an environment in which the two processes are connected by an imaginary tube.

Sending & Receiving Buffers

  

TCP needs buffers for storage because of the speed disparity that might happen between sending & receiver. Buffers are maintained as a circular array of 1 bytess at both sides. At the sending site, buffer has 3 types of chambers. - A white section : Which contains empty chambers that can be filled by sending process. - A gray area that holds bytes that have been sent but not acknowledged. TCP keeps these bytes in buffer until it receives an acknowledgement. Once it receives acknowledgment, chambers are recycled. - Colored area contains bytes to be send by sending TCP.

   

At the receiving side, circular buffer is divided into two areas white & coloured. White area contains chambers to be filled by bytes received from network. Coloured section contains received bytes that can be read by receiving process. When a byte is received by the receiving process, chamber is recycled & added to the pool of empty chambers.

Figure 12.3 Sending and receiving buffers

Segments
      

Although, buffering handles disparity between speed of producing & consuming processes, one more step is required before we can send data. IP is the service provider for TCP, & it needs to send data in packets, not as a stream of bytes. At transport layer, TCP groups a number of bytes together into a packet called segment. TCP adds a header to each segment & delivers the segment to the IP layer for transmission. Segments are encapsulated into IP datagram, & transmitted. This operation is transparent to the received process. Segments are not necessarily of the same size.

Reliable service It uses an acknowledgment mechanism to check safe & sound arrival of data.

Figure 12.5 TCP segment format

Source Port address 16 bit field, defines the port number of the application program in the host that is sending the segment. Destination Port address 16 bit field, defines port number of the application program in the host that is receiving the segment. Sequence No 32 bit field, defines the number assigned to first byte of data contained in this segment. To ensure connectivity, each byte to be transmitted is numbered. Sequence number tells destination which byte in this sequence comprises first byte in segment.

Acknowledgement No. Is 32 bit field, defines the byte number that the receiver of the segment is expecting to receive from another party. If receiver of segment has successfully received byte number x from other party, it defines x+1 as ack no.

Figure 12.6 Control field

Window size This field defines size of window in bytes, that the other party must maintain. This value is referred to as the receiving window, rwnd & is determined by the receiver. Sender must obey the dictation of the receiver in case.

Checksum 16 bit field contains checksum. Calculation of checksum for TCP follows same procedure. Urgent pointer -16 bit field, which is valid only if the urgent flag is set, is used when the segment contains urgent data. It defines the number that must be added to the sequence number to obtain the number of the last urgent byte in the data section of the segment.

Encapsulation.


TCP segment is encapsulated in an IP datagram, which is encapsulated in a frame at data-link layer. Frame Header

IP header

TCP Segment

TCP Connection
 

 

Connection Establishment in TCP is called three-way handshaking. Server program tells its TCP that, it is ready to accept a connection. This is called a request for passive open. It cannot make the connection itself. Client program issues a request for active open. A client that wishes to connect to an open server, tells its TCP that it needs to be connected to that particular server. The three steps in this phase are : Client sends first segment, SYN segment, in which, only SYN flag is set. This is for synchronization of sequence nos. Client chooses a random number as the first sequence no & sends this to server. This is called ISN. (Initial Sequence No.) This does not contain ack no, does not define window size. SYN does not carry data. It consumes one sequence no. Once data transfer starts, SYN segment is incremented by 1.

Server sends second segment, SYN + ACK segment, with SYN & ACK flags set. SYN is for communication in other direction. It also acknowledges the receipt of SYN segment from client, by setting ACK flag & displaying the next seq no. it expects from client. Since it contain acknowledgement, it needs to define the receiver window size, rwnd. It does not carry data, but consume 1 sequence number. Client sends third segment. This is the ACK segment. It acknowledges the receipt of second segment with ACK flag & ack number field. Sequence number is the same as in SYN segment. It does not consume seq number, if not carrying data, but must define window size. It can carry data too, but usually does not carry data.

Simultaneous open


This is a rare situation, occurring when both processes issue an active open. In this case, both TCPs transmit SYN +ACK segment, to each other & one single connection is established between them.

SYN flooding attack

 

  

The connection establishment procedure in TCP is susceptible to a serious security problem called SYN flooding attack. This happens when a malicious attacker sends a large number of SYN segments, to a server, pretending that, each of them is coming from a different client, by faking the source IP addresses in the datagrams. Server, assuming that, clients are issuing an active open, allocates the necessary resources, such as creating TCB tables. TCP server, then sends the SYN+ACK segments, to the fake clients, which are lost. During this time, a lot of resources are occupied without being used. If , during this time, the number of SYN segments are large, server eventually runs out of resources & may crash. This SYN flooding attack, belongs to a group of security attacks, known as Denial of service attack, in which attacker monopolizes a system with so many service request, that the system collapses & denies service to every requests.

Solutions
  

Imposing a limit of connection requests during a specified period of time. Filtering out datagrams, coming from unwanted source address. Postpone resource allocation until , the entire connection is setup using cookie.

Data Transfer
 

After connection is established, bidirectional data transfer can take place. Client & server can send data & acknowledgements in both directions.

Connection Termination


Any of the two parties involved in exchanging data, can close the connection, though it is usually initiated by client. Most implementations allow 2 options for connection termination 3 way handshaking & 4-way hand shaking with a close option.

Three way handshaking



In normal situation, the client TCP, after receiving a close command from the client process, sends the first segment FIN segment, in which FIN flag is set. It can include the last chunk of data sent by the client or it can be just a control segment. If it is only a control segment, it consumes only 1 sequence no. The server TCP after receiving the FIN segment, informs its process of situation, and sends the second segment, FIN + ACK segment, to confirm the receipt of FIN segment from the client & at the same time, to announce the closing of connection in other direction. This can also contain the last chunk of data from server. IF it does not carry data, it consumes only sequence number. Client TCP sends the last segment, an ACK segment, to confirm the receipt of the FIN segment, from TCP server. This contains the ack no, which is one + sequence number received in the FIN segment, from the server. This segment, cannot carry data & consumes no sequence number.

Figure 12.9 Connection establishment using three-way handshaking

Figure 12.10 Data transfer

Figure 12.11 Connection termination using three-way handshaking

Half-close
    

In TCP, one end can stop sending data, while still receiving data. This is called a half-close. Although, either end can issue a half-close, it is normally initiated by the client. It can occur when the server needs all the data before processing can begin. Eg: sorting. A client can half-close the connection, by sending FIN segment. The server accepts half-close by sending ACK segment. Data transfer from client to server stops. Server can however send data. When server has sent all of the processed data, it sends an FIN segment, which is acknowledged by an ACK from the client. After half-closing the connection, data can travel from server to client & acknowledgments from client to server. Client cannot send any more data to server.

 

Second segment, consumes no sequence no. Though , the client has received sequence no. y1, & is expecting y, server sequence no. is still y1. When connection finally closes, sequence no.of last ACK is still x, because, no sequence no. is consumed during data transfer in that direction.

Figure 12.12 Half-close

Connection Reset
  

 

TCP at one end may deny a connection request, may abort a connection or may terminate an idle connection. All are done with RST flag. Denying a connection : Happens when TCP at one side request a connection to a non existent port. Tcp at other end may send a segment with RST bit set to annul the request. Aborting a connection : EG. Abnormal situation Terminating idle connection : Tcp at one end, notices that TCP on other end, has been idle for long time. IT sends RST segment, to destroy the connection.

Pushing the data.

  

A push operation is requested to handle delayed transmission & delayed delivery of data. Eg. Interactive applications. Here, sending TCP must not wait for the window to be filled, to send data, it must create a segment & send it immediately. Sending TCP must also set the push bit (PSH) to let the receiving TCP know that the segment includes data that must be delivered to the receiving application program, as soon as possible & not to wait for more data to come. TCP can choose whether or not to use this feature.

Urgent Data
   

To handle urgent situations, sending application sends a segment with URG bit set. Sending application program tells the sending TCP, that the piece of data is urgent. Sending TCP creates a segment & inserts the urgent data at the beginning of the segment. The rest of the segment can contain normal data from the buffer. The urgent pointer field in the header defines the end of the urgent data & start of normal data. When the receiving TCP receives a segment with URG bit sent, it extracts the urgent data from the segment, using the value of urgent pointer, & delivers it , out of order, to the receiving application program. Eg: A situation where, sending application , after sending a huge amount of wrong data & wanting to abort the process, after realising the mistake.

Flow Control
Regulates the amount of data a source can send before receiving an ack from destination. In extreme case, a transport layer protocol could send 1 byte of data & wait for an ack before sending next byte. This would be extremely slow process. If data are traveling a long distance, source is idle while it waits for an ack. At other extreme, a transport layer protocol, can send al of the data without worrying about ack. This speeds up process, but it may overwhelm the receiver. Besides, if some part of data is lost, duplicated, received out of order, or corrupted, source will not know until all has been checked by destination. The solution defined for this by TCP is Sliding window. IT defines a window, that is imposed on the buffer of data delivered from the appn program & ready to be sent. Tcp sends an amt of data defined by sliding window protocol.

Sliding window protocol

 

 

Used by TCP to accomplish Flow Control. Here, a host uses a window for sending data. The window spans a portion of the buffer containing bytes received from the process. Bytes inside the window are the bytes can be in transit- they can be sent without worrying about ack. The imaginary window has two walls left & right. Window is called sliding window coz, right & left walls can slide.

Figure 12.20 Sliding window

Note: A sliding window is used to make transmission more efficient as well as to control the flow of data so that the destination does not become overwhelmed with data. TCPs sliding windows are byte oriented.

   

3 activities associated with window are window is opened, closed, or shrunk. These 3 are in the control of receiver, not the sender. Sender must obey the commands of receiver in this matter. Opening window moving right wall to right. This allows more new bytes in the buffer, that r eligible for sending. Closing window moving left wall to the right. This means some bytes have been acknowledged & the sender needs not worry about them anymore. Shrinking window Moving right wall to left. This is discouraged, coz, it would revoke the eligibility of some bytes for sending.

  

Sliding window is used to make transmission more efficient as well as to control the flow of data so that, the destination does not become overwhelmed with data. Size of window at one end is determined by the lesser of 2 values rwnd (receiver window) & cwnd(congestion window). Rwnd is the no. of bytes the other end can accept before its buffer overflows & data is discarded. Cwnd is a value determined by the network to avoid congestion.

Note: To avoid shrinking the sender window, the receiver must wait until more space is available in its buffer.

Note:
Some points about TCPs sliding windows:
The size of the window is the lesser of rwnd and cwnd. The source does not have to send a full windows worth of data. The window can be opened or closed by the receiver, but should not be shrunk. The destination can send an acknowledgment at any time as long as it does not result in a shrinking window. The receiver can temporarily shut down the window; the sender, however, can always send a segment of one byte after the window is shut down.

Silly Window Syndrome.



 

 

This is a serious problem that can arise in the sliding window operation when either the sending application program creates data slowly or the receiving appn program consumes data slowly or both. Any of these situations results in the sending of data in very small segments, which reduces the efficiency of operation. For eg: If TCP sends segments containing only 1 byte of data, it means that a 41 byte datagram (20 bytes IP + 20 bytes TCP header), transfers only 1 byte of user data. Here, the overhead is 41/1, which indicates that we are using the capacity of the network very inefficiently. This problem is called silly window syndrome.

Syndrome created by the sender.



Sending TCP may create a silly window syndrome if it is serving an appn program that creates data slowly. Eg. 1 byte at a time. Appn program writes 1 byte at a time into the buffer of the sending TCP. If it does not have any specific instructions, it may create segments, containing 1 byte of data. Result is a lot of 41 byte segments that are traveling through internet. Solution in Nagles Algorithm.

Nagles Algorithm
 

Sending TCP sends first piece of data it receives from the sending appn program, even if it is only 1 byte. After sending the first segment, sending TCP accumulates data in the output buffer & waits, until either the receiving TCP sends an ack on until enough data has accumulated to fill a max size segment. At this time, the sending TCP can send segment. Step 2 is repeated for the rest of transmission. Segment 3 must be sent if an ack is received for segment 2 or if enough data have accumulated to fill a max size segment. Elegance of Nagles algorithm is in its simplicity & in the fact that it takes into account the speed of appn process that creates data & speed of network that transports data. If appn program is faster than the network, segments are larger (max size segments) else, segments r smaller (< than max size).

Syndrome created by reciever

 

  

Receiving TCP may create silly window syndrome, if it is serving an appn pgm that consumes data slowly. For eg,1 byte at a time. Eg : Sending appn program creates data in blocks of 1 kb, but receiving appn consumes data 1 byte at a time. Also suppose that the input buffer of receiving TCP is 4kb. Sender sends 1st 4kb of data, receiver stores it in buffer. Now the buffer is full. It advertises a window size of 0, which means, sender should stop sending data. Receiving appn reads first byte of data from input buffer of receiving TCP. Now there is 1 byte of space in the incoming buffer, receiving TCP announces window size of 1 byte, which means that sending TCP , which is eagerly waiting to send data, takes this advt, & sends segment carrying only 1 byte data.

 

 

The procedure will continue. One byte of data is consumed & a segment carrying 1 byte data is sent. Again, there is a silly window syndrome. Two solutions to prevent silly window syndrome created by an appn program that consumes data slower than they arrive are : Clarkss solution. Delayed Acknowledgement.

  

Clarks solution : Is to send an ack as soon as the data arrives, but to announce a window size of 0, until either there is enough space to accommodate a segment of max size or until half of buffer is empty. Delayed acknowledgment. : Second solution is to delay sending the ack. This means, when a segment arrives, it is not ack immediately. Receiver waits until there is a decent amount of space in its incoming buffer before acknowledging arrived segments. The delayed ack prevents the sending TCP from sliding its window. After it has sent the data in the window, it stops. This kills the syndrome. Delayed ack reduces traffic aswell. Receiver does not have to ack each segment. Disadv is that, it may force the sender to retransmit unack segments. Protocol balances pros & cons, by defining that ack should not be delayed by more than 500 ms

TCP Timers
    

To perform its operation smoothly, most TCP implementations use atleast 4 timers. Retransmission timer Persistence timer Keepalive timer Time-wait timer

Retransmission Timer
To retransmit a lost segment, TCP employs a retransmission timer that handles the retransmission timeout (RTO) , the waiting time for an ack of a segment.  When TCP sends a segment, it creates a retransmission timer for that particular segment. 2 situations can occur : - If an ack is recd for this particular segment before the timer goes off, the timer is destroyed. - If timer goes off before ack arrives, segment is retransmitted, & timer is reset. To calculate retransmission timeout , RTO, we need to calculate round trip time(RTT).


Round trip time (RTT)

  

Measured RTT Measures how long it takes to send a segment & receive an ack for it. Segments & their ack do not have a 1-1 relnship, several segments may be ack together. Measured round trip time (RTTM) for a segment is the time required for the segment, to reach the destination & be acknowledged, although ack may include other segments. In TCP, only 1 RTTM can be in progress at any time.

Smoothed RTT
  

RTTM changes for round trip. Fluctuation is so high in Internet that it cannot be used for retransmission timeout purposes. Most implementations use a smoothed RTT RTTS which is a weighted average of RTTM & previous RTTS. Original -> No value After first measurement -> RTTS = RTTM After any other measurement -> RTTS = (1-)RTTS + .RTTM

The value is implementation dependent, but is normally to 1/8. ie, new RTTS is calculated as 7/8 of the old RTTS & 1/8of the current RTTM.

RTO
  

Is based on the smoothed round trip time & its deviation. Original -> Initial value After any measurement -> RTO=RTTS + 4.RTTD

RTT Deviation is based on RTTS & RTTM.  Original -> No value  After first measurement -> RTTD = RTTM/2  After any other measurement -> RTTD =(1) RTTD + . | RTTS RTTM |  Value of is also impl dep, but is usually set to .

Problem definition
 

 

: A segment is not acknowledged during the retransmission period & is therefore, retransmitted. When sending TCP receives an ack for this segment, it does not know if ack is for the original segment or for the retransmitted one. Value of new RTT is based on the departure of the segment. However, if the original segment was lost & ack is for the retransmitted one, value of current RTT must be calculated from the time the segment was retransmitted. This is a dilemma that was solved by Karn.

Karns algorithm
   

Is a solution to the defined problem. It states : Do not consider the RTT of a retransmitted segment in the calculation of new RTT. Do not update the value of RTT until u send a segment & receive an ack without the need for retransmission.

Persistence Timer
 

    

To deal with a 0 window size advt, TCP needs another timer. If receiving TCP announces a window size of 0, the sending TCP stops transmitting segments until the receiving sends an ACK segment, announcing a non-zero window size. This ACK segment can be lost. (ACK segments are not acknowledged in TCP) If this ack is lost, receiving TCP thinks that it has done its job & waits for sending TCP to send more segments. There is no retransmission timer for a segment containing only an ack. The sending TCP has not received an ack & waits for the other TCP to send an ack advertising the size of the window. Both TCPS can continue to wait for each other , creating a deadlock.

       

To correct this deadlock, TCP uses a persistent timer for each connection. When sending TCP receives an ack with a window size of 0, it starts a persistent timer. When the persistent timer goes off, sending TCP sends a special segment called probe. This segment contains only 1 byte of data. It has a sequence no., but is seq no is never acknowledged. IT is even ignored in calculating the sequence number for the rest of the data. The probe alerts the receiving TCP that the acknowledgement was lost & must be resent. Value of persistence timer is set to the value of retransmission time. IF a response is not recd from the receiver, another probe segment is sent, value of persistence timer is doubled & reset.

Sender continues sending the probe segments & doubling & resetting the value of persistence timer until the value reaches a threshold (usually 60s). After that, sender sends one probe segment every 60s until the window is reopened.

Keepalive timer
 

  

Used in some implementations to prevent a long idle connection between two TCPs. EG . If a client opens a TCP connection to a server, transfers some data & becomes silent. Perhaps the client has crashed. In this case, the connection remains open forever. To remedy this situation, most implementations equip a server with a keepalive timer. Each time the server hears from a client, it resets this timer. The timeout is usually 2 hrs. If there is no response after 10 probes , each of which is 75s apart, it assumes that the client is down & terminates the connection.

Time-wait timer


The Time-wait (2MSL) timer is used during connection termination.

Note: In TCP, there can be only be one RTT measurement in progress at any time.

EXAMPLE 10

Let us give a hypothetical example. Figure 12.38 shows part of a connection. The figure shows the connection establishment and part of the data transfer phases.
1. When the SYN segment is sent, there is no value for RTTM , RTTS , or RTTD . The value of RTO is set to 6.00 seconds. The following shows the value of these variables at this moment: RTTM = 1.5 RTTD = 1.5 / 2 = 0.75 RTTS = 1.5 RTO = 1.5 + 4 . 0.75 = 4.5

2. When the SYN+ACK segment arrives, RTTM is measured and is equal to 1.5 seconds. The next slide shows the values of these variables:

EXAMPLE 10 (CONTINUED)

RTTM = 1.5 RTTD = 1.5 / 2 = 0.75

RTTS = 1.5 RTO = 1.5 + 4 . 0.75 = 4.5

3.When the first data segment is sent, a new RTT measurement starts. Note that the sender does not start an RTT measurement when it sends the ACK segment, because it does not consume a sequence number and there is no time-out. No RTT measurement starts for the second data segment because a measurement is already in progress.
RTTM = 2.5 RTTS = 7/8 (1.5) + 1/8 (2.5) = 1.625 RTTD = 3/4 (7.5) + 1/4 |1.625 2.5| = 0.78 RTO = 1.625 + 4 (0.78) = 4.74

Figure 12.38 Example 10

Note: TCP does not consider the RTT of a retransmitted segment in its calculation of a new RTO.

EXAMPLE 11

Figure 12.39 is a continuation of the previous example. There is retransmission and Karns algorithm is applied. The first segment in the figure is sent, but lost. The RTO timer expires after 4.74 seconds. The segment is retransmitted and the timer is set to 9.48, twice the previous value of RTO. This time an ACK is received before the time-out. We wait until we send a new segment and receive the ACK for it before recalculating the RTO (Karns algorithm).

Figure 12.39 Example 11

Error Control
 

 

TCP provides reliability using error control. Error control includes mechanisms for detecting corrupted segments, lost segments, out-of-order segments, duplicated segments. It also includes a mechanism for correcting errors after they are detected. Error detection & correction is achieved through the use of 3 simple tools checksum, acknowledgement, timeout.

       

Checksum : Each segment includes checksum field, which is used to check for a corrupted segment. In TCP, inclusion of checksum is mandatory. If the segment is corrupted, it is discarded by the destination TCP & is considered as lost. Acknowledgment : TCP uses ack to confirm the receipt of data segments. Control segments that carry no data, but consume a sequence number, are also acknowledged. Ack segments are not acknowledged. There is no ve acknowledgment. If not acknowedged before timeout, segments are considered to be either corrupted or lost. Acknowledgment can be accumulative or selective. ACK is positive, ie, it doesnt report discarded, lost or duplicated segments. ACK acknowledges receipt of segments accumulatively. ACK is implemented in the TCP header as 32 bit ack field. SACk reports even out-of-order & duplicated segments. There is no provision in header for adding SACK information, hence implemented as an option at the end of header.

Note: ACK segments do not consume sequence numbers and are not acknowledged.

Note: In modern implementations, a retransmission occurs if the retransmission timer expires or three duplicate ACK segments have arrived.

Note: No retransmission timer is set for an ACK segment.

Note: Data may arrive out of order and be temporarily stored by the receiving TCP, but TCP guarantees that no out-of-order segment is delivered to the process.

Figure 12.25 Normal operation

Figure 12.26 Lost segment

Note: The receiver TCP delivers only ordered data to the process.

Figure 12.27 Fast retransmission

Figure 12.28 Lost acknowledgment

Figure 12.29 Lost acknowledgment corrected by resending a segment

Note: Lost acknowledgments may create deadlock if they are not properly handled.

12.8 CONGESTION CONTROL

Congestion control refers to the mechanisms and techniques to keep the load below the capacity. capacity.

The topics discussed in this section include: Network Performance Congestion Control Mechanisms Congestion Control in TCP

  

Retransmission : The heart of error control mechanism is retransmission of segments. When a segment is corrupted, lost or delayed, it is retransmitted. A segment is retransmitted on two occasions When a retransmission timer expires or when the sender receives three duplicate ACKs. ACk segments are not retransmitted.

 

Retransmission is handled using RTO & Three duplicate ACK segments. Source TCP starts one RTO timer for each segment sent. When timer matures, corresponding segment is considered to be corrupted or lost. & segment is retransmitted, even though, lack of a recd ACK can be due to a delayed segment, delayed ACK or lost ack. When one segment is lost & the receiver receives so many out of order segments, that, they cannot be saved, most implementations follow 2 duplicate ACKs rule & retransmit missing segment immediately. This feature is referred to as fast retransmission.

Congestion Control
 

    

Congestion is an important issue in network. It may occur if load on the network the no.of packets sent to the network, is greater than capacity of the network the number of packets a network can handle. A router has buffer that stores incoming packets. Congestion occurs when router receives packets faster than it can process them. When congestion occurs, some packets may be dropped, hence no acknowledgement will be sent for the same. Sender then, retransmits the lost packet, which leads to more congestion. Tcp assumes, that cause of lost segment is due to congestion in the network. If the cause of lost segment is congestion, retransmission of the segment aggravates congestion.

Congestion control refers to the mechanisms & techniques to control the congestion & keep load below capacity. Congestion happens because routers and switches have queues buffers that hold the packets before & after processing. A router has an input & output queues for each interface. Congestion control involves 2 factors that measure performance of a network Delay & throughput.

 

 

Delay versus load : When load is much less than capacity of network, delay is at minimum. When load reaches network capacity, delay increases sharply because we now need to add the waiting time in the queues for al routers in the path, to the total delay. Delay becomes infinite, when load is greater than capacity. It has a ve effect on the load & consequently the congestion. When a packet is delayed, source, not receiving an acknowledgement, retransmits the packet, which makes the delay & congestion worse. Fig.

    

Throughput versus load : Throughput is the no. of packets, passing through the network in a unit of time. When load is below the capacity of network, throughput increases proportionally with load. After load reaches capacity, throughput sharply declines as packets get discarded by the routers. When load exceeds capacity, queues become full & routers have to discard some packets. Discarding packets does not reduce the no. of packets in the network because, sources retransmit the packets, using timeout mechanisms, when the packets do not reach destinations.

Congestion Control in TCP



Tcps general policy for handling congestion is based on 3 phases.

  

slow start congestion avoidance congestion detection using Fast Retransmission & Fast recovery algorithm.

       

In slow start phase, sender starts with a very slow rate of transmission, but increases the rate rapidly to reach a threshold. When the threshold is reached, data rate is reduced, to avoid congestion. Finally, if congestion is detected, sender goes back to the slow start or congestion avoidance phase, based on how the congestion is detected. Slow Start : Exponential Increase : Is one of the algorithms used in TCP congestion control. It is based on the idea that size of congestion window starts with one maximum segment size. (MSS) Size of window increases one MSS each time one segment is acknowledged. Algorithm starts slowly, but grows exponentially. Eg. Fig.

Slow start cannot continue indefinitely. There must be a threshold to stop this phase. Sender keeps track of a variable named ssthresh. When size of window in bytes reaches this threshold, slow start stops, next phase starts.

Congestion avoidance : Additive Increase

   

 

If we start with slow start algorithm, size of congestion window increases exponentially. To avoid congestion before it happens, one must slow down this exponential growth. Tcp defines another algorithm called congestion avoidance, which increases additively instead of exponentially. When size of congestion window reaches slow start threshold, slow start phase stops, & the additive phase begins. In this algorithm, each time the whole window of segments is acknowledged, size of cwnd is increased by 1. Eg. Fig.

Congestion Detection : Multiplicative Decrease

    

If congestion occurs, cwnd size must be decreased. Only way the sender can guess that congestion has occurred, is the need to retransmit a segment. But, retransmission can occur in one of the 2 cases : When RTO timer times out, or when 3 ACKs are received. In both the cases, size of threshold is dropped to half. (Multiplicative decrease). If a time-out occurs, there is stronger possibility of congestion : - A segment has probably been dropped In the network, & there is no news abt the following sent segments. In this case, TCP reacts strongly.
  

It sets value of threshold to half of current window size. It sets cwnd to size of one segment It starts slow start phase again.

If three ACKs are received, there is a weaker possibility of congestion; a segment may have been dropped, but some segments after that may have arrived safely since 3 ACKs are received. This is called fast transmission & fast recovery. Here TCP reacts weaker.
  

It sets value of threshold to half of current window size. It sets cwnd to the value of threshold. It starts congestion avoidance phase.

 

If detection is by timeout, a new slow start phase starts. If detection is by three ACKs, a new congestion avoidance phase starts.

Figure 12.30 Router queues

Figure 12.32 Throughput versus network load

Figure 12.33 Slow start, exponential increase

Note: In the slow start algorithm, the size of the congestion window increases exponentially until it reaches a threshold.

Figure 12.34 Congestion avoidance, additive increase

Note: In the congestion avoidance algorithm the size of the congestion window increases additively until congestion is detected.

Note:
Most implementations react differently to congestion detection:
If detection is by time-out, a new slow start phase starts. If detection is by three ACKs, a new congestion avoidance phase starts.

Figure 12.35 TCP congestion policy summary

Figure 12.36 Congestion example

12.9 TCP TIMERS

To perform its operation smoothly, most TCP implementations use at least four timers. timers.

The topics discussed in this section include: Retransmission Timer Persistence Timer Keepalive Timer TIME-WAIT Timer TIME-

Options
TCP header can have upto 40 bytes of optional information.  It conveys additional info to the destination or align other options.  Categorized into : 1 byte & Multiple Byte options. Single byte End of option list No operation Options Maximum segment size Window scale factor Multiple byte Time stamp Sack-permitted Sack


  

EOP(End-of-option) is a 1 byte option used for padding at the end of option section. Only 1 occurrence of this option is allowed. This option imparts 2 pieces of info to the destination .
There are no more options in the header.  Data from application program starts at the beginning of next 32 bit word. 3 byte option EOP  Can be used only once. Eg ; Used for padding


Data

No operation (NOP) : Is a 1 byte option used as a filler. Normally comes before another option to make an option fit in a 4-word slot. Eg : Used to align one 3 byte option such as window scale factor & one 10 byte option such as timestamp. NOP can be used more than once.

Used to align beginning of an option

NOP NOP NOP 10 byte option 3 byte option

Data

MSS maximum segment size

   

 

It defines the size of the biggest unit of data that can be received by the destination of the TCP segment. It defines the maximum size of data, not the maximum size of the segment. Since the field is 16 bits long, the value can be 0 to 65535 bytes. MSS is determined during connection establishment & does not change during the connection. Each party defines the MSS for the segments it will receive during connection. If a party does not define this, default value is 536 bytes. Format is as shown : 1 1 2
Kind : 2 00000010 Length : 4 00000100 MSS

Window Scale Factor

  

Window size field in the header defines the size of the sliding window. This field is 16 bits long, which means that window can range from 0 to 65535 bytes. Though this seems like a very large window size, it still may not be sufficient, especially if data is travelling through a long fat pipe, with a wide bandwidth. To increase the window size, a window scale factor is used. New window size is found by first raising 2 to the number specified in the window scale factor. Then, this result is multiplies by the value of the window size in the header. Kind : 3 Length : 3 Scale factor
00000011 00000011

 

New window size = window size defined in the header * 2 window scale factor. Scale factor is sometimes called shift count coz, multiplying a number by a power of 2 is the same as a left shift in bitwise operation. Largest value allowed by TCP is 14, which means that max window size is 216 * 214 = 230, which is less than the max value for the sequence no. Size of the window cannot be greater than the maximum value of the sequence no. Window Scale factor can also be determined only during the connection establishment phase. Does not change during connection. During data transfer, size of window may be changed, but it must be multiplied by same window scale factor.

Timestamp
 

This is a 10 byte option . The end with active open announces a timestamp in the connection request segment (SYN). If it receives a timestam in the next segment, (SYN + ACK) from the other end, it is allowed to use the timestamp. Otherwise, it does not use it anymore. It has 2 applications : It measures Round Trip Time & prevents wraparound sequence numbers. Format is as below.

Kind :8 00001000

Length : 10 00001010

Timestamp value Timestamp echo reply

SACK permitted & SACK options.

  

    

ACK field in the TCP segment is designed as an accumulative acknowledgement, which means it reports the receipt of the last consecutive byte. It does not report the bytes that have arrived out of order. It is also silent about duplicate segments. This may have a ve effect on TCPs performance. If some packets are lost or dropped, the sender must wait until a time-out & then send all packets that have not been acknowledged. Receiver may receive duplicate packets. To improve performance, selective acknowledgment (SACK) was proposed. SACK allows the sender to have a better idea of which segments are actually lost & which have arrived out of order. Sender can then send only those segments that are really lost. List of duplicate segments can help the sender find the segments which have been retransmitted by a short timeout. Two new options are Sack- permitted & SACK.

 

SACK-permitted option : Is Of 2 bytes, used only during connection establishment. The host that sends the SYN segment adds this option to show that it can support SACK option. If the other end, in its SYN+ACK segment, also includes this option, then two ends can use the SACK option during data transfer. SACK-permitted option is not allowed during data transfer phase. SACK option : Variable length, - is used during data transfer phase only if both ends agree. (If they have exchanged SACK-permitted options during connection establishment). It includes a list for blocks arriving out-of-order. Each block occupies two 32 bit numbers, that define the beginning & end of blocks.

State Transition Diagram



     

To keep track of all different events happening during connection establishment, data transfer & connection termination, tcp software is implemented as a finite state machine. It is a machine that goes through a limited number of states. At any moment , machine is in one of the states. Event is an input supplied to a state , which changes state & can also create an output. In state transition diagram, ovals represent states. Transition from one state to another is represented using directed lines. Each line has 2 strings, separated by a slash. First string is the input, second is the output what tcp sends.

 

The dotted black lines in the figure represent the transition that a server normally goes through. Solid black lines show the transitions that a client normally goes through. Coloured line shows special situations.

Client States
      

The client process issues a command to its TCP to request a connection to a specific socket address. This is called Active Open. TCP sends a SYN segment,& moves to SYN-SENT state. After receiving SYN + ACK segment, TCP sends an ACK segment & goes to Established State. After this state, Data transfer take place in both directions, possibly & acknowledged. When client process has no more data to send, it issues a command called Active Close. The client Tcp sends a FIN segment, & goes to FIN-WAIT-1 state. When it receives the ACK for the sent FIN, it goes to FIN-WAIT-2 state & remains there, until it receives a FN segment from the server.

 

When the FIN segment is received, client sends an ACK segment & goes to the TIME-WAIT state & sets a timer for a time-out value of twice the MSL. MSL is the maximum segment time a segment can exist in the Internet before it is dropped. Once the timeout expires (which is usually 30 s to 1 Min), client goes to the CLOSED state .

Server States
  

 

Server process issues an OPEN command. This must happen before the client issues an open command. Server TCP goes to the LISTEN state & remains there, passively, until it receives a SYN segment. When server TCP receives a SYN segment, it sends a SYN + ACK segment & goes to SYN-RCVD state, waiting for the client t send an ACK segment. After receiving the ACK segment, it goes to ESTABLISHED state, where data transfer can take place. TCP remains in this state until it receives a FIN segment from the client TCP signifying, that there are no more data to be sent & the connection can be closed. At this moment, server sends an ACK to the client, delivers outstanding data in its queue to the application & goes to the CLOSE-WAIT state.

   

This is a scenario of half-close connection, where server tcp can still send data to the client & receive ack, but no data can flow in other direction. Server TCP remains in this state until the application actually issues a close command. It then sends a FIN to the client to show that it is closing the connection as well & goes to LAST-ACK state. It remains in this state, until it receives the final AC, when it goes to the CLOSED state. The termination beginning with first FIN is called 4-way handshaking.

TCP Numbering System

   

Although TCP Software keeps track of the segments being transmitted or received, there is no field for a segment number value in the segment header. Instead, there are two fields, called Sequence No & Acknowledgement Number. They refer to Byte No. & not segment No. Byte No. :
     

The bytes of data being transferred in each connection are numbered by TCP. Numbering starts with a randomly generated number & need not necessarily start from 0. TCP Generates a random number between 0 & 2 32 1for the number of first byte. If the random number happens to be 1057 & the total data to be sent is 6000 bytes, bytes are numbered from 1057 to 7056. Numbering is independent in each direction. When TCP receives bytes of data from a process, it stores them in the sending buffer & numbers them.

Sequence No.
    

After the bytes have been numbered, TCP assigns a sequence no. to each segment that is being sent. The sequence no. for each segment is the number of the first byte carried in that segment. When a segment carries a combination of data & control info (piggy-backing), it uses a sequence number. If segment does not carry user data, it does not define sequence no. Control segments may carry one byte, but no actual data. If the randomly generated seq no. is x, first data byte is numbered x + 1. They are used for connection establishment, data transfer, termination.

Acknowledgment No.
     

When a connection is established, both parties can send & receive data at the same time. Each party numbers the bytes, usually with a different starting byte number. Sequence no. in each direction shows the number of the first byte carried by the segment. Each party also uses an ack number to confirm the bytes it has received. Value of ack field in a segment defines the number of the next byte a party expects to receive. Ack no. is cumulative. Ie, if a party announces ack number as x, it means that the party has received all bytes from the beginning up to x-1.

Table 12.3 States for TCP

Figure 12.13 State transition diagram

Figure 12.14 Common scenario

Figure 12.16 Simultaneous open

Figure 12.17 Simultaneous close

Figure 12.18 Denying a connection

Figure 12.19 Aborting a connection