%%% sctp-report.tex --- 

%% Author: prashmohan@gmail.com
%% Version: $Id: sctp-report.tex,v 0.0 2006/03/26 09:49:22 prash Exp$


\documentclass[12pt,a4paper,oneside]{article}
\usepackage[debugshow,final]{graphics}
\newcommand{\name}{Prashanth~Mohan}
\newcommand{\addr}{II-B, Mahadev Flats, 22, Chockalingam Nagar, Near D.M.S, Chennai - 600 086}
\newcommand{\phone}{(044)~2434~8648}
\newcommand{\email}{prashmohan@gmail.com}
\newcommand{\website}{http://www.prash.be}

\usepackage[left=2cm,top=1cm,right=3cm,nohead,nofoot]{geometry}
\begin{document}

\title{Network Lab Mini-Project Report\\Simulation of \textit{SCTP} (Stream Control
  Transmission Protocol)} 
\author{Prashanth Mohan\\20032169 \and Venkateswaran S\\20032219}
\maketitle


\section{What is \textit{SCTP}}
\textit{\textbf{SCTP}} is a reliable transport protocol operating on top
of a potentially unreliable connectionless packet service such as IP. It offers
acknowledged error-free non-duplicated transfer of datagrams
(messages). Detection of data corruption, loss of data and duplication
of data is achieved by using checksums and sequence numbers. A selective
retransmission mechanism is applied to correct loss or corruption of
data. \textit{SCTP} is defined in RFC 2960

\section{How is it different from \textit{TCP}}
\begin{itemize}
  \item Multi-Streaming -- Several streams within same connection
  \item Multi-Homing -- More than 1 Network Interface
  \item TCP is a stream of bytes whereas \textit{SCTP} is a stream of messages
  \item Checksum field of 32 bits
  \item Uses \textit{adler-32} algorithm for chechsum which is more reliable
\end{itemize}

\section{Multi-Homing}

\begin{center} \includegraphics[scale=1.0]{multihoming.gif} \end{center}
Multi-homing provides applications with higher availability than those
that use TCP. A multi-homed host is one that has more than one network
interface and therefore more than one IP address for which it can be
addressed. In TCP, a connection refers to a channel between two
endpoints (in this case, a socket between the interfaces of two
hosts). SCTP introduces the concept of an association that exists
between two hosts but can potentially collaborate with multiple
interfaces at each host.
SCTP monitors the paths of the association using a built-in heartbeat;
upon detecting a path failure, the protocol sends traffic over the
alternate path. It's not even necessary for the applications to know
that a failover recovery occurred.

\section{Multi-Streaming}
\begin{center} \includegraphics[scale=1.0]{multihoming.gif} \end{center}
Each stream is given a stream number that is encoded inside SCTP packets
flowing through the association. Multi-streaming is important because a
blocked stream (for example, one awaiting re-transmission resulting from
the loss of a packet) does not affect the other streams in an
association. This problem is commonly referred to as head-of-line
blocking. TCP is prone to such blocking.
Multi-streaming is an important feature of SCTP, especially when you
consider some of the control and data issues in protocol design. In TCP,
control and data typically share the same connection, which can be
problematic because control packets can be delayed behind data
packets. If control and data were split into independent streams,
control data could be dealt with in a more timely manner, resulting in
better utilization of available resources.

\section{Data Transmission}
\subsection{Connection Setup}
\begin{center} \includegraphics[scale=1.0]{init.gif} \end {center}
The problem that can occur with TCP is when a rogue client forges an IP
packet with a bogus source address, then floods a server with TCP SYN
packets. The server allocates resources for the connections upon receipt
of the SYN, then under a flood of SYN packets, eventually runs out and
is unable to service new requests. This is called a Denial of Service
(DoS) attack.
SCTP protects against this type of attack through a four-way handshake
and the introduction of a cookie. In SCTP, a client initiates a
connection with an INIT packet. The server responds with an INIT-ACK,
which includes the cookie (a unique context identifying this proposed
connection). The client then responds with a COOKIE-ECHO, which contains
the cookie sent by the server. At this point, the server allocates the
resource for the connection and acknowledges this by sending a
COOKIE-ACK to the client.

\subsection{Message Framing}
\begin{center} \includegraphics[scale=1.0]{msg.gif} \end {center}
With message framing, the boundaries in which messages are communicated
through a socket are preserved; this means that if a client sends 100
bytes to a server followed by 50 bytes, the server will read 100 bytes
and 50 bytes, respectively, for two reads. UDP also operates in this
way, which makes it advantageous for message-oriented protocols.
In contrast, TCP operates in a byte-stream fashion. Without framing, a
peer may receive more or less than was sent (splitting up a write or
aggregating multiple writes into a single read). This behavior requires
that message-oriented protocols operating over TCP provide data-buffer
and message framing within their application layer (a potentially
complex task).

\subsection{Configureable Unordered Delivery}
Messages in SCTP are transferred reliably but not necessarily in the
desired order. TCP guarantees that data is delivered in order (which is
a good thing, considering TCP is a stream protocol). UDP guarantees no
ordering. But, you can also configure streams within SCTP to accept
unordered messages if desired.
This feature can be useful in message-oriented protocols in which
requests are independent and ordering is not important. Further, you can
configure unordered delivery on a stream-by-stream basis within an
association.

\subsection{Connection Shutdown}
\begin{center} \includegraphics[scale=1.0]{shut.gif} \end {center}
In TCP, it's possible for a peer to close its end of a socket (resulting
in a FIN packet being sent) but then to continue to receive data. The
FIN indicates that no more data is to be sent by this endpoint, but
until the peer closes its end of the socket, it may continue to transmit
data. Applications rarely use this half-closed state, and therefore the
SCTP designers opted to remove it and replace it with a cleaner
termination sequence. When a peer closes its socket (resulting in the
issuance of a SHUTDOWN primitive), both endpoints are required to close,
and no further data movement is permitted in either direction.

\end{document}