~rmyeid/+junk/euler

\chapter{TCP}

TCP\footnote{Transmission Control Protocol} becomes the de facto standard protocol

 for the nowadays applications. Application protocols like HTTP, FTP, SSH are all

  built upon TCP, because TCP provides enough functionality to create reliable applications.\\

TCP provides reliable connection whatever the the stack under the TCP is, connection

 oriented communication, with flow control and congestion avoidance mechanisms.

  All these services make TCP the most complicated layer in the current OSI model.

  All these services are provided making use of error detection, multiplexing, retransmissions,

   commulative acknowledgments, timers.\cite{topdown}

 

TCP is defined mainly in RFC 793, but as time goes on many other variants appeared

 to tune TCP to different environments and to fix performance issues. Most of the

  modifications came later addressed the congestion problem in networks.

 

\section{Flow Control}\label{TCP:Flow control}

This mechanism aims to not overwhelm the receiver with the data transferred. The sender maintain

the following variables the receive window, last byte acknowledged, last byte sent. Receive window guarantee that data received at the

receiver buffer and the data transferred along the connection will not be larger than the receiver buffer. The receive window

variable is updated in the sender from the receive window field in the acknowledgements. The field is calculated in the receiver

According to the following equation:

\begin{verbatim} RcvWindow=RcvBuffer-[LastByteRcvd - LastByteRead]\end{verbatim}

If the receiver do not have any acknowledgement to send the sender keeps a persist timer, so it sends a dummy small packet 

the timer timeouts, so it can get an acknowledgement from the receiver which updates the 

receive window variable. Which is important if it is equal to zero.

\section{Congestion Avoidance}\label{TCP:Congestion Avoidance}

Due to the limitations we have on real networks like finite buffer sizes, many practical

issues arise. Finite buffers will drop any further data received if they are full, those dropped

packets according to the reliable data transfer mechanism will be retransmitted again. Which make the

system in a deadlock situation! To solve such problem many mechanisms are applied. The following are the most 

used ones:

\begin{itemize}

\item \textbf{Slow Start} 

TCP starts in this mode.Slow Start begins with the congestion window, called

 \verb+cwnd+ , containing one segment. After each acknowledgement

the cwnd increases by one, which result in doubling the \verb+cwnd+ size each Round 

Trip Time (RTT), and it continues till \verb+cwnd+ reaches the minimum of the congestion window,

 and the receive window. When a lost packet or acknowledgement detected by a timeout

occurring or the receipt of duplicate ACKs. The \verb+cwnd+ will be reset to 1 segment and ssthresh will set to the 

half of the current \verb+cwnd+.

\item \textbf{Congestion Avoidance}

This mode declare a new variable called Slow Start Threshold \verb+ssthresh+ which maintains half of the \verb+cwnd+

size when the last congestion happened. When the current \verb+cwnd+ reaches the \verb+ssthresh+ the \verb+cwnd+ will

exit the slow start mode and enter the congestion avoidance mode which make the 

increments of the \verb+cwnd+ occur in linear behavior instead of the exponential one.

\item \textbf{Fast Retransmit}

Instead of waiting the sender timer to timeout, duplicate acknowledgement is a strong

indication of a reordering or few lost packet, receiving three or more duplicate 

acknowledgements means that it is not a reordering problem. Few lost packets does not

imply a strong congestion so a direct retransmission occur on the sender after receiving 

duplicate acknowledgements. Fast retransmit utilizes the link throughput.

 

\item \textbf{Fast Recovery}

Fast retransmit implies the beginning of the congestion, so fast recovery mechanism

apply the congestion avoidance instead of slow start which reduces \verb+cwnd+. "It is an improvement that allows high

   throughput under moderate congestion, especially for large windows"\cite{2001}.

 

\end{itemize}

  

\section{TCP Variants}\label{TCP:TCP Variants}

Due to the intensive research done on the TCP performance issues, many variants appeared, the following are 

the most popular ones:

 

\begin{enumerate}

\item \textbf{TCP Tahoe}

is the original design. When a loss detected the \verb+cwnd+ will set to one segment and

 TCP will enter the slow start mode.

\item \textbf{TCP Reno}

is the most implemented TCP, it uses the above mechanisms listed above: Slow Start

, Congestion Avoidance, Fast Retransmit, Fast Recovery.

\item \textbf{TCP Vegas}

uses AIMD\footnote{Additive Increases/Multiplicative Decreases} algorithm in the congestion window, the difference is

is that Tahoe detects the loss depending on the change in the RTT, which makes it

depending heavily on  calculating the RTT in precise way.

\item \textbf{TCP newReno}

improves throughput during the fast recovery mode, by advancing the \verb+cwnd+ for each acknowledged

packet, which keeps the transmit window full.For every ACK that makes partial progress in the sequence space,

 the sender assumes that the ACK points to a new hole, and the next packet beyond the ACKed sequence number is sent.

 It seems like the SACK\footnote{Selective Acknowledgement} behaviour.

\end{enumerate}