\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Modified TCP for Time Critical Applications},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2014-01-15 (revised: 15 January 2014)}
\def\TheID{\makeatother }
\def\TheDate{2014-01-15}
\title{Modified TCP for Time Critical Applications}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Abhay Kumar  1}

             \affil[1]{  1 JB Institue of Engineering and Technology, Hyderabad, 2. Chaitanya Bharthi Institute of Technology, Hyderabad, 3. Jawaharlal Nehru Technological Uni}

\renewcommand\Authands{ and }

\date{\small \em Received: 10 December 2013 Accepted: 1 January 2014 Published: 15 January 2014}

\maketitle


\begin{abstract}
        


A network is defined to be a congested networkif the load on the network exceeds the capacity of the network. The traditional congestion control technique of slow-start and AIMD was adopted when the aim was more on the stability of the Internet. But as more and more time critical applications such as multimedia applications are being used, we need alternate technique that reduces the drastic fluctuations of window size present in the existing technique. Thispaper proposes a techniquefor fast delivery of packet for a time critical application.  It reduces the packet overhead and time compared to existing slow-start and AIMD technique. The proposed technique uses information or intelligence from the unexpected packet received. It is a fine modification of the existing slow-start and AIMD technique by adapting them for time critical applications. We propose modification at both thesender and the receiver hosts without modifying anything in the intermediate hosts of the network. Extensivesimulation show that proposed technique reduces congestion in the network by reducing both packet overhead and time compared to the traditional slow-start and AIMD technique and delivers the packets in timely manner than the existing techniques.

\end{abstract}


\keywords{network protocols, TCP, congestion control, slow-start, aimd.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
he Internet is a global network of interconnected computers which allows individuals and organizations around the world to communicate and share information with each other. This demand has natural fluctuation; therefore, the Internet performance is largely governed by it, leading to possible congestion which occurs when resource demands exceed the capacity of the network. Due to the explosive growth of the Internet and increasing demand for multimedia applications like voice over IP, real-time video streaming, IPTV and financial transactions, the issue of congestion has received tremendous attention from academia and industry. Transmission of real-time multimedia applications typically has large bandwidth, small delay and low-loss requirements. However, the current Internet does not guarantee any quality of service (QoS) as it is based on best-effort service model of IP \hyperref[b0]{[1]}. A network is said to be congested from the perspective of a user if the service quality noticed by the user decreases because of an increase in network load. The goal of congestion control mechanisms is simply to use the network as efficiently as possible, that is, attain the highest possible throughput while maintaining a low loss ratio and small delay. Congestion must be avoided because it leads to queue growth and queue growth leads to delay and loss \hyperref[b1]{[2} As the network grew, it was clear that unrestricted data transfer by many users over a shared resource, i.e., the Internet, could be bad for the end users; excess load on the links leads to packet loss and decreases the effective throughput. This kind of loss was experienced at a significant level in the '80s and was termed congestion collapse \hyperref[b4]{[5]}. Thus, there was a need for a protocol to control the congestion in the network, i.e., control the overloading of the network resources. It led to the development of a congestion control algorithm for the Internet by  {\ref Van Jacobson [5]}. This congestion control algorithm was implemented within the protocol used by the end hosts for data transfer called the Transmission Control Protocol (TCP).\par
There are several different flavors of TCP congestion control, each of which operates somewhat differently. But most of the versions of TCP are windowbased protocols, wherein the idea is that each user maintains a number called a window size, which is the number of unacknowledged packets that are allowed to be sent into the network. Any packet from the new window can be sent only when an acknowledgment for the last packet in the previous sent window is received by the sender. TCP adapts the window size in response to congestion information. The window size is increased if the sender determines that there is excess capacity present in the route and decreases if the sender determines that the current number of in-flight packets exceeds the capacity of the route. The exact means of determining whether to increase or decrease the window size is what determines the difference between the congestion control mechanisms of different TCP flavors. The most commonly used TCP flavors used for congestion control in the Internet today are Reno and New Reno \hyperref[b11]{[12]}. Both of them are updates of the TCP-Tahoe, which was introduced in 1988 \hyperref[b4]{[5]}. Although, they vary significantly in many regards, the basic approach to congestion control is similar. The idea is to use successful reception of packets as an indication of available capacity and dropped packets as an indication of congestion. In most cases, eachtime the destination receives a packet, it sends an acknowledgement (also called ACK) asking for the next packet in sequence to be transmitted. When an acknowledgment for a windowis received, the protocol increases its window size. However, on reception of three duplicate acknowledgments or dupacks (i.e., four successive( D D D D D D D D )\par
Year 2014 identical acknowledgments) by the sender is taken by it as an indication that packet has been lost due to congestion. In case the source does not receive any acknowledgement for a finite time (RTO \hyperref[b12]{[13]}), it assumes that all unacknowledged packets have been lost. In both the cases the source aggressively proceeds to cut down the window size and retransmit the lost packets.\par
TCP Vegas improves upon TCP Reno through three main techniques. The first is a new retransmission mechanism where timeout is checked on receiving the first duplicate acknowledgment, rather than waiting for the third duplicate acknowledgment, and results in a more timely detection of loss. The second technique is a more prudent way to grow the window size during the initial use of slow-start when a connection starts up, and it results in fewer losses. The third technique is a new congestion avoidance mechanism that corrects the oscillatory behavior of Reno. The idea is to have a source estimate the number of its own packets buffered in the path and try to keep this number between ? (typically 1) and ? (typically 3) by adjusting its window size. The window size is increased or decreased linearly in the next round-trip time according to whether the current estimate is less than ? or greater than ?. Otherwise the window size is unchanged. The rationale behind this is to maintain a small number of packets in the pipe to take advantage of extra capacity when it becomes available. A source periodically measures the round-trip queuing delay and sets its rate to be proportional to the ratio of its round-trip propagation delay to queuing delay, the proportionality constant being between ? and ?. Hence, the more congested its path, the higher the queuing delay and the lower the rate. The Vegas source obtains queuing delay by monitoring its round-trip time (the time between sending a packet and receiving its acknowledgment) and subtracting from it the round-trip propagation delay \hyperref[b6]{[7]}.\par
In today's Internet, real-time applications such as VoIP, videoconferencing and on-line gaming mostly use RTP over UDP or UDP alone to transport data. Because these protocols are unresponsive to congestion events, the growing popularity of applications that use them endangers the stability of the Internet. So, to make it possible that real-time applications are widely adopted, common congestion control mechanisms suitable for real time multimedia are expected to be deployed  {\ref [3] [4]}.\par
The existing techniques does not use any information or intelligence from the unexpected packet received, unexpected packets are simply discarded. The proposed techniques tries to retrieve information based on the unexpected packet received and perform the congestion control accordingly.\par
The remaining paper is organized as follows: Section II explains the system or network model used in this paper. Section III describes our proposed Unexpected Packet based Congestion Control (UPCC) Technique. Section IV presents the simulation results that demonstrate our proposed UPCC technique reduces congestion in the network compared to traditional slow-start and AIMD technique. Finally Section V concludes the paper. 
\section[{II.}]{II.} 
\section[{System Model}]{System Model}\par
This paper considers a realistic computer network consisting of several sources and destinations connected via multiple routers and links. The source (sender) communicates to the destination (receiver) in form of packets. The series of routers and links that a packet follows from the source to destination is called a route. A pair of sender and receiver may be connected via multiple routes. This network is represented in the Figure \hyperref[fig_0]{1}. For simplicity of the explanation, we consider only a pair of sender (S) and receiver (R) connected via multiple routes, as shown in Figure \hyperref[fig_1]{2}. The sender and the receiver may be running multiple different applications. However, the packets of the application are transmitted using the first come first serve policy. The connection is established using three-way handshake as in case of existing TCP. However, this paper proposes few modifications in this phase also to make the subsequent transmissions congestion aware. Year 2014 
\section[{E}]{E}\par
TCP operates in two distinct phases. When file transfer begins, the window size is 1, but the source rapidly increases its transmission window size so as to reach the available capacity quickly. Let us denote the window size by W. The algorithm increases the window size by 1 each time an acknowledgement for a packet indicating success is received. This is called the slowstart phase. Since one would receive acknowledgements corresponding to one window's worth of packets in an RTT \hyperref[b12]{[13]}, and we increase the window size by one for each successful packet transmission, this also means that (if all transmissions are successful) the window would double in each RTT, so wehave an exponential increase in rate as time proceeds. Slow-start refers to the fact that the window size is still small in this phase, but the rate at which the window is increased is quite rapid. When the window size either hits a threshold, called the slow-start threshold (ssthresh) or the transmission suffers a loss (immediately leading to a halving of window size), the algorithm shifts to a more conservative approach called the congestion avoidance phase. When in the congestion-avoidance phase, the algorithm increases the window size by 1 every time feedback of a successful packet transmission in the corresponding window is received. When a packet loss is detected by the receipt of three dupacks, the slow-start threshold (ssthresh) is set to half of the current window i. e TCP Reno cuts its window size by half (W ? W/2) and algorithm enters additive increase phase where it start sending segments from current window onwards. Thus, in each RTT, the window increases by one packet i.e., a linear increase in rate. Protocols of this sort where increment is by a constant amount, but the decrement is by a multiplicative factor are called additive increase multiplicative decrease (AIMD) protocols. When packet loss is detected by a timeout, the slow-start threshold (ssthresh) is set to half of the current window and the algorithm enters the slow-start phase i.e., it start sending from 1 packet onwards. Let us call the congestion window at time t as W (t). This means that the number of packets in-flight is W (t). The time taken by each of these packets to reach the destination, and for the corresponding acknowledgement to be received is RTT. The RTT is a combination of propagation delay and queuing delay. A window-based congestion control scheme defines one control rule for window increase, and another rule forwindow decrease. AIMD uses the following control rule \hyperref[b15]{[19]}:Increase:?? ??+1 ? ?? ?? + ??, ?? > 0 Decrease:?? ?? ? ?? ?? ? ???? ?? , 0 < ?? > 1\par
Where ? and ? refer to the additive increase constant and multiplicative decrease constant ? respectively. The standard TCPuses the value of these constants ? and ? as 1 and 0.5 respectively.\par
This subsection provides the definition of several terms and the notations that will beused throughout the remainder of this paper.\par
? SYN: To establish a connection, TCP uses a threeway handshake. Synchronize (SYN) \hyperref[b8]{[9]} packet is the first control packet sent for the three-way handshake by the sender wishing to establish the TCP connection.\par
? ACK: An acknowledgement (ACK) [14] is a control packet used between communicating processes or computers to signify receipt of receiving a data packet, and it is a part of a communication protocol. For example, ACK packets are used in the Transmission Control Protocol (TCP) to acknowledge the receipt of SYN packets while establishing a connection in three-way handshake, and acknowledge the receipt of data packets while a connection is in data transfer phase.\par
? SS-AIMD: In the Slow-Start (SS) \hyperref[b4]{[5]} [8] and Additive Increase Multiplicative Decrease (AIMD) \hyperref[b4]{[5]} [14] algorithm, when a TCP connection first starts, the slow-start phase initializes a congestion window to one packet and transmits. After receiving acknowledgement from the receiver, the window increases by one packet for each acknowledgement returned. After successful transmission of these two packets and acknowledgements received, the window is increased to four packets and so on, doubling from there up to a threshold known as slow-start threshold (ssthresh). After slow-start threshold, the algorithm enters into additive increase multiplicative decrease (AIMD) phase where window increases by one packet for successful transmission of all the packets in the window i.e., additive increase. In this phase, the transmission rate slows down to avoid congestion. But whenever a packet is lost, the sender immediately sets its transmission window to one half of the current window size i.e., multiplicative decrease.\par
? ssthresh: Slow-start threshold (ssthresh) [2] is a point where slow-start phase ends and additive increase multiplicative decrease (AIMD) phase starts.\par
? dupacks: When receiver receives a TCP packet with a sequence number higher than the expected one (out of turn packet). The receiver sends an immediate ACK with the Acknowledgement field set to the Sequence number the receiver was expecting. This ACK is a duplicate of an ACK (dupacks) \hyperref[b1]{[2]} which was sent previously. This is done to update the sender with regards to the missing TCP packets.\par
? rwnd: Receiver advertised window (rwnd) \hyperref[b9]{[10]} or receiver queue capacity is the most recent advertised window that contains the number of packets a receiver can process. This is one of the ? cwnd: Congestion window (cwnd) [12] is a TCP state variable maintained at the sender that limits the amount of data a TCP can transmit without facing congestion through the network. At any given time, a TCP transmit minimum of congestion window and receiver advertised window.\par
? TCP: The Transmission Control Protocol (TCP)  {\ref [14]} is used as a highlyreliable host-to-host protocol between hosts in packet-switched computercommunication networks, and in interconnected systems of such networks.TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of transport layer protocolswhich support multi-network applications. The TCP provides for reliable interprocess communicationbetween pairs of processes in host computers attached to distinct but interconnected computer communication networks.\par
? UDP: The User Datagram Protocol (UDP) [15] is defined as a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP)  {\ref [16]} is used as the underlying protocol. User Datagram Protocol is unreliable connection-less protocol used at transport layer ? IP: The Internet Protocol (IP) [17] is designed for use in interconnected systems ofpacket-switched computer communication networks. The internet protocol provides fortransmitting blocks of data called datagram from sources to destinations. The internet protocol also provides forfragmentation and reassembly of long datagram, if required, fortransmission through "small packet" networks. Internet Protocol is unreliable connection-less protocol used at network layer ? RTP: The real-time transport protocol (RTP) \hyperref[b14]{[18]} provides end-to-end network transport functions suitable forapplications transmitting real-time information, like audio, video ordata, over multicast or unicast network services. RTP does not provide resource reservation and also does not guarantee quality-of-service for real-time services. This transport protocol is also augmented by another real-time control protocol (RTCP) to allow monitoring of the data delivery in amanner scalable to large multicast networks, and to provide minimalcontrol and identification functionality. RTP and RTCP are designedto be independent of the underlying transport and network layers.\par
? VoIP: Voice over Internet Protocol (VoIP) \hyperref[b2]{[3]} is a mechanism that allows telephone calls to be made over computer networks like the Internet. VoIP converts analog voice signals into digital data packets and supports real-time, two-way transmission of conversations using Internet Protocol.\par
? IPTV: Internet Protocol television (IPTV) \hyperref[b2]{[3]} is the process of transmitting and broadcasting television programs using the Internet protocol suite over a packet-switched network such as the Internet, instead of being delivered through traditional terrestrial, satellite signal and cable television formats.\par
? RTO: The retransmission timeout (RTO) [13] is aretransmission timer used by the Transmission Control Protocol to ensure data delivery in the absence of anyfeedback from the remote data receiver. The duration of this timeris referred to as RTO. The retransmission timeout timer is used for retransmissions of lost or delayed packet.\par
? RTT (?): Round trip time (RTT) \hyperref[b12]{[13]} is the length of time it takes for a packet to be sent and the length of time it takes for an acknowledgment of that packet to be received  The proposed technique is a fine modification of the existing slow-start and AIMD technique by adapting it and making congestion aware. We propose modification at both the sender and receiver hosts without modifying anything in the intermediate hosts of the network. The proposed modification can be described in the form of a dialogue between sender and receiver from initiation to the termination of a connection. 
\section[{At sender side:}]{At sender side:}\par
Whenever a sender host wants to communicate it will send a SYN (i) packet to the receiver host expressing its desire to communicate as in existing technique \hyperref[b7]{[8]}  \hyperref[b8]{[9]}. On sending the SYN(i) packet the sender will start a timer based on RTT within which it should ideally receive an ACK (i+1) packet from the receiver. This can be seen in Figure \hyperref[fig_5]{3}. In case, he does not receive an ACK (i+1) packet, he assumes that there is congestion in the network and therefore it retransmit SYN (i) packet with doubled RTT. This information about congestion is stored in a separate variable 'C' that will be used in data transfer stage, i.e., it set C=1. This communication can be seen in Figure \hyperref[fig_6]{4}.  At receiver side: On receiving a SYN(i) packet it will send an ACK(i+1) packet containing its available queue capacity 'rwnd' together with its own SYN(j) and set C=0 to inform its readiness for communication and no congestion perceived so far. To complete the three-way handshake of TCP connection it starts its timer waiting for an ACK (j+1) from sender for his SYN (j) as shown in Figure \hyperref[fig_7]{5}. However, if it receives unexpected duplicate SYN (i) message or no ACK (j+1) within its RTT, it indicates that its ACK (i+1) or ACK (j+1) was lost and hence congestion may be present. It responds to this new SYN (i) received or RTT time out by retransmitting with a packet containing SYN(j), ACK(i+1), and rwnd. This information about congestion is stored in a separate variable 'C' that will be used in data transfer stage, i.e., it set C=1. This communication can be seen in Figures \hyperref[fig_8]{6 and 7}. proposed technique presumes network to be congestion free. Thus, it advocates an aggressive start wherein the window size is set to be equalto the receiver queue capacity 'rwnd'. On the other hand, a congestion may be perceived when C=1 at either the sender or receiver side. In such case we follow the same existing Figure  {\ref 6} : Three-way handshake when ACK from sender is lost. slow-start and AIMD technique \hyperref[b4]{[5]} [8] for selecting the window size. After the selection of window size is made, the data transfer phase is initiated by the sender and the dialogue continues as follows:\par
Algorithm for window selection start If C=0 Window Size = rwnd // we apply aggressive start i.e., it does not depend on cwnd as per standard TCP \hyperref[b4]{[5]} If C=1 Window Size = min (cwnd, rwnd) // we apply the standard TCP rule i.e., slow-start with AIMD \hyperref[b7]{[8]} stop At sender side:\par
The sender will start sending the packets up to the window size (W s , W end ) but it doesn't expects any ACK till it completes sending the entire window. In other words, it expects one ACK (w end ) per window. In ideal condition it will receive the ACK (w end ) and assumes no congestion C=0 and will adjusts the window as per the policy defined above, in the algorithm for window selection. 
\section[{At receiver side:}]{At receiver side:}\par
On receiving the ACK (j+1) with the window size it will set its window and will wait to receive the data packets. When requisite packets arrive it acknowledges them by sending ACK (w end ) for the same. However, at any point of time, if it feels overloaded or underloaded, it will send its updated queue capacity 'rwnd' to the sender piggybacking with ACK(k) where k-1 is the last packet accepted from the sender. 
\section[{At sender side:}]{At sender side:}\par
If it receives an unexpected ACK (k) (as it expects only ACK (w end ) for any window) then it will simply slides the window such that it starts with the first unacknowledged packet, i.e., packet with sequence number k. Further, it adjusts the window according to the new 'rwnd' suggested by the receiver. Thus, on receiving one unexpected ACK (k) the sender simply slides and adjust the window size and again expects one ACK (w end ) within the RTT of the new window. This communication can be seen in Figure \hyperref[fig_9]{8} where 'k = n+3' and new 'rwnd = 12'. At receiver side:\par
The above dialogue presumes that no congestion exists and hence, no packet loss occurs. However, if the receiver finds an out of turn packet it indicates that the intermediate packet/s could be lost. In such case it will send an ACK (k) with current 'rwnd' for the last in order packet i.e k-1 received. It will also slide its window but it does not expect a retransmission of the intermediate packet/s as they may be delayed. However, if it further receives second out of the turn packet it presumes that intermediate packet/s is lost. It sends a duplicate ACK (k) with current 'rwnd' and starts a timer based on RTT within which it should receive the lost packet. In case it does not, it will resend an ACK (k). This communication can be seen in Figure \hyperref[fig_10]{9}. On receiving the first unexpected ACK (k), the sender simply slides the window as was discussed in Figure \hyperref[fig_9]{8}. But if it receive a duplicate ACK (k), i.e., two ACK (k) it indicates that mild congestion is present in the network. This assumption of mild congestion is based on the understanding between sender and receiver that two duplicate acknowledgements will be send by the receiver only when the receiver receives two out of turn packets. Therefore, it must retransmit only that missing k th packet and continue with sending the packets from first non-transmitted packets in the current window and expect the ACK (w end ) for the current entire window. This communication can be seen in Figure \hyperref[fig_10]{9}.\par
At receiver side:\par
On receiving the missing packet, it will place it in order and continue receiving till the end of window. If all the packets arrive, the receiver will send the ACK (wend). However, if it misses another packet in the same window, it indicates that the congestion is increasing and it will send the duplicate ACK (j) with 'rwnd'=rwnd/2 as shown in Figure \hyperref[fig_11]{10}. If sender receives another pair of unexpected ACK (j) in its current window, it indicates that the second packet in the same window has been lost implying that window size is too big. In such scenario the sender will slide the window to the first unacknowledged packet and retransmit the missing packet. It will also reduce its transmission window as indicated by the receiver to half. This communication can be seen in Figure \hyperref[fig_11]{10}.After transmission of the entire window the sender waits for RTT time to receive the acknowledgement ACK (wend). If it receives ACK (wend) within the stipulated time then he assumes that the network is congestion free and continues with the next window. However, if ACK wend) is not received within the RTT the sender presumes high congestion in the network. It retransmits the first packet in the window as shown in Figure \hyperref[fig_0]{11}, and starts the timer with RTT time as perexisting slow-start and AIMD algorithm \hyperref[b4]{[5]}   At receiver side: If retransmission of a packet which is not asked by the receiver i.e., unexpected packet is received. The receiver will transmits the ACK (k) where k-1 is the last in order packet received. As demonstrated in the Figure \hyperref[fig_0]{11}, when the sender retransmits the first packet of the last unacknowledged window i.e., Ws=n+9 when it does not receive ACK (n+15) i.e., ACK (W end ) within its RTT, the Figure \hyperref[fig_0]{11} : Data transfer phase when ACK(W end ) for complete window is lost receiver will respond by retransmitting the ACK (n+15) i.e., ACK (W end ) indicating the receipt of the complete window n+9 to n+14. By doing this the receiver avoids the retransmission of the remaining packets in the last unacknowledged window i.e., n+10 to n+14. For large window this is substantial reduction in retransmission improving the throughput of the network and reducing congestion. 
\section[{At sender side}]{At sender side}\par
It may receive a unexpected delayed ACK (Wend) in response to Ws retransmitted by it for the previous window. As shown in Figure \hyperref[fig_0]{11}, it receives ACK (n+15) i.e., ACK (W end ) in response to its retransmission of packet W s =n+9. Theexisting techniques \hyperref[b7]{[8]} will discard this ACK (W end ). However, in the proposed technique it is not simply discarded but is used to indicate mild congestion and the previous window packets have been received without any problem. Thus, sender should stop retransmission and recover from slow-start phase by sliding the window up to the first unacknowledged packet and continue with the original window size.\par
Both sender and receiver utilize the congestion information received for one connection over all other connections made by them leading to recovery from the congestion by the network.\par
The proposed Unexpected Packet based Congestion Control (UPCC) technique is illustrated with the following motivational example which will illustrate the limitations of existing techniques.\par
Let an application have 1024 packets and as considered by the authors in \hyperref[b9]{[10]}  \hyperref[b10]{[11]}, the slow-start threshold (ssthresh) as 40 packets and receiver advertised window (rwnd) as 50 packets, we also consider the same. We estimate the packet overhead gain and the time gain for the existing slow-start AIMD technique and the proposed UPCC techniques as follows.\par
a) Existing SS-AIMD \hyperref[b7]{[8]} technique in congestion free network\par
The existing slow-start technique \hyperref[b4]{[5]} will initially set the window as one packet. When its corresponding ACK arrives, the source sets the corresponding window to two packets. It then transmits two packets. On receiving the two corresponding ACK, it sets the window size to four and so on. Therefore, the slow start technique increases the window size from 1 exponentially up to ssthreshold of 40 packets, forming a geometric progression of 1, 2, 4, 8, 16, and 32. From ssthreshold to rwnd, it will perform additive increase as arithmetic progression of 40, 41, 42, 43, 44, 45, 46, 47, 48, 49 and 50. Beyond rwnd, the current size of the window cannot increase because it has to be minimum of cwnd and rwnd, thus it remains constant at rwnd. The existing technique during the slow start phase will expect an acknowledgement per packet, while in the subsequent phase only one ACK per window will be received. Hence, apart from the 1024 data packet additionally 84 ACK packets will be required.\par
However, to give the existing technique a fair chance we assume that only one ACK per window is required. Mathematically, the minimum number of ACKs required to transmit the application of 1024 packets in congestion free network is?? ?? = ?? ???? + ?? ???? + ? ???????????? ???? ?????????????? ???? ???? ???????????????????? ?(?? ???? +?? ???? ) ???????? ? Where ?? ???? =??????? 2 ??????????????? ?? ???? = (rwnd-ssthresh)+1 ?? ???? = (???????? ?????????????? ? +1)(????????????? ? +???????? ) 2\par
?? ???? =2 ??????? 2 ????????????? ? ? -1 Thus, the variation in window size will be as 1,  {\ref 2, 4, 8, 16, 32,40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50,50, 50, 50, 50, 50, 50, 50, 50, 50and 16}. In other words, additional X\textunderscore E=27 number of acknowledgements must be sent by the receiver to acknowledge the correct The time required by the slow-start technique to transmit initial packets in the windows of 1, 2, 4, 8, 16, and 32 will be ? + (?+?) + (?+3?) + (?+7?) + (?+15?) + (?+31?) where ? is RTT and ? is the time to transmit consecutive packet in a window. Similarly, the time required for transmitting packets in the remaining windows can be estimated. Therefore, the total time required by the slow-start and AIMD technique will be T E = 27? + 997?.\par
In the following subsection we discuss packet overhead gain and time gain for the proposed Unexpected Packet based Congestion Control technique in congestion free network. 
\section[{b) Proposed UPCC technique in congestion free network}]{b) Proposed UPCC technique in congestion free network}\par
In congestion free network, the proposed UPCC technique advocates the use of rwnd (receiver advertised window) as a window size for the transmission. Therefore, the number of ACKs required for transmitting the application of 1024 packets will be?? ?? = ? ???????????? ???? ?????????????? ???? ???? ???????????????????? ???????? ?\par
Hence, X P =21, implying 21 acknowledgements are required as compared to 27 acknowledgements in the existing technique. Thus, approximately 22\% reduction in the number of acknowledgements is achieved through proposed UPCC technique. Further, the time required to transmit an application of 1024 packets will be ?? ?? = (?+49?) × 20 + (? + 23?)= 21? + 1003?. Thus, the proposed UPCC technique reduces the time by approximately 12\% leading to lesser chance of congestion in the network.\par
In the following subsection we discuss packet overhead gain and time gainin congested network where packet loss may occur while transmitting this application. c) Existing SS-AIMD \hyperref[b7]{[8]} technique with single packet loss Consider that 240 th packet is lost while transmitting 11 th window where 44 packets can be transmitted without waiting for the acknowledgement. When receiver receives out of turn packets, it sends duplicate acknowledgement. When the sender receives 3 duplicate ACKs, it indicates mild congestion. The existing algorithm updates ssthreshold, cwnd and window size as ???????????????????? = cwnd 2 ? , ???????? = ????????????????????, and ???????????? ???????? = min(????????, ????????) respectively. It retransmits the lost packet and enters in to AIMD phase directly. In AIMD phase, the window starts increasing additively from new calculated ssthreshold to rwnd(receiver advertised window) as arithmetic progression. Thus, the variation in window size will be  {\ref 1, 2, 4, 8, 16, 32,40, 41, 42, 43, 44(loss occurs),22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42}, 43 and 37. Thus, ?? ?? = 34 + 3, i.e., 37 acknowledgements which include three duplicate acknowledgements must be sent by the receiver to acknowledge the correct receipt of each window, causing the packet overhead on the network. The total time required for this process will be ?? ?? = 34? + 991?.\par
The subsection discusses the performance of the proposed technique under the same scenario. 
\section[{d) Proposed UPCC technique with single packet loss}]{d) Proposed UPCC technique with single packet loss}\par
When 240 th packet is lost and receiver receives the 241 st packet after the receipt of 239 th packet. It sends an acknowledgement for the correct receipt of 239 th and expecting 240 th packet, i.e., ACK (240). However, when it receives the 242 nd packet it will resend the ACK (240). When sender receives two ACK (240), it retransmits the lost packet and keeps the ???????????? ???????? = ????????(receiver advertised window) indicating mild congestion. Thus, the proposed UPCC technique in congested network with single packet loss requires,?? ?? = 23, acknowledgements where 2 extra acknowledgements are used for informing loss of 240 th packet. Approximately 38\% and 24\% reduction in the packet overhead and time is achieved respectively.\par
Further, the performance of the proposed UPCC technique is evaluated with respect to the existing SS-AIMD technique under severe congestion wherein the ACK is not received within the stipulated RTO time, i.e., when RTO timer expires. e) Existing SS-AIMD technique \hyperref[b4]{[5]} when RTO timer expires Whenever sender's RTO timer expires before receiving acknowledgement, it indicates severe congestion. The sender presumes that the entire window is lost and starts retransmission by reducing the window size back to one. In the above example, while transmitting an application consisting of 1024 packets if the RTO timer expireswhen the sender window is 44. The algorithm updates ssthreshold, cwnd and window size as ssthreshold = current window 2 ? , cwnd = 1 and window size = min(cwnd, rwnd) respectively. It then starts retransmission by entering into slow-start phase where the window size increases exponentially from 1 up to new ssthreshold of 22 packets as geometric progression. After this it enters in AIMD phase, where the window size increases additively from new ssthreshold calculated to rwnd(receiver advertised window) as arithmetic progression. Thus, the variation in window size will be 1, 2, 4, 8, 16, 32, 40, 41, 42, 43, 44(timer expires), 1, 2, 4, 8, 16, 22, 23, 24, 25,?, 44 and finally 5. Hence, ?? ?? = 40 number of acknowledgements must be sent by the receiver. The total time required by the existing SS-AIMD technique when timer expires will be ?? ?? = 44? + 1028?. The performance of the proposed Unexpected Packet based Congestion Control (UPCC) technique when RTO timer expires is as follows: f) Proposed UPCC technique when RTO timer expires Whenever sender's RTO timer expires before receiving an acknowledgement, it indicates severe congestion due to single or multiple packet loss. In the proposed technique the sender starts retransmission of the first unacknowledged packet and waits for RTO time again. In its response the receiver will send the ACK of the last correctly received packet with the rwnd. This ACK will indicate that how many packets are lost. If one packet loss is perceived then the proposed technique will assume that the network had mild congestion and has recovered from it so it will continue with the rwnd received i.e., 50, 50, 50, 50, 50(timer expires), 1, 50, 50,?, 50, and 25. However, if multiple packets are lost then it updates rwnd and window size as ???????? = ???????? 2 ? , and ???????????? ???????? = ???????? respectively. This reduction in window size will continue if repeatedly multiple packet loss occur , however, the window size will be boosted on successful transmission of a complete window as 50, 50, 50, 50, 50(timer expires), 1, 25, 50, 50, 50, ?,50 and 48. Therefore, approximately 42\% and 40\% reduction in packet overhead is received in case of single and multiple packet loss when timer expires respectively. Further, reduction in the transmission time is perceived as approximately 35\% and 32\% lower for the proposed UPCC technique in the case of single and multiple packet lossrespectively when timer expires.\par
The above example demonstrated that as more and more packet are lost the performance of the proposed UPCC technique improves both in terms of packet overhead gain and time gain.\par
IV. 
\section[{Simulation Results}]{Simulation Results}\par
We perform extensive network simulations with the help of ns-2, the widely used open-source network simulator \hyperref[b16]{[20]}. We compared our proposed Unexpected Packet based Congestion Control (UPCC) technique with traditional slow-start and AIMD technique (NewReno \hyperref[b11]{[12]}) and found that proposed UPCC technique reduces the packet overhead by 22\% to 40\% as shown in Figure \hyperref[fig_1]{12} and also reduces the time to transmit an application by 12\% to 32\% as depicted in Figure \hyperref[fig_5]{13}. The variations in packet overhead and time depend on the level of congestion present in the network. The simulations were conducted in three different categories as 1) congestion free 2) single packet loss and 3) multiple packet loss.     Year 2014 E\begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Figure 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_2}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-5.png}
\caption{\label{fig_4}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-6.png}
\caption{\label{fig_5}Figure 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-7.png}
\caption{\label{fig_6}Figure 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5}\includegraphics[]{image-8.png}
\caption{\label{fig_7}Figure 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7}\includegraphics[]{image-9.png}
\caption{\label{fig_8}Figure 7 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{8}\includegraphics[]{image-10.png}
\caption{\label{fig_9}Figure 8 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{9}\includegraphics[]{image-11.png}
\caption{\label{fig_10}Figure 9 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{10}\includegraphics[]{image-12.png}
\caption{\label{fig_11}Figure 10 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-13.png}
\caption{\label{fig_12}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-14.png}
\caption{\label{fig_14}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-15.png}
\caption{\label{fig_16}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1213}\includegraphics[]{image-16.png}
\caption{\label{fig_17}Figure 12 :Figure 13 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1417}\includegraphics[]{image-17.png}
\caption{\label{fig_18}Figure 14 :Figure 17 :}\end{figure}
   \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.0616580310880829\textwidth}P{0.7560449050086355\textwidth}P{0.007340241796200345\textwidth}P{0.01468048359240069\textwidth}P{0.010276338514680483\textwidth}}
?? ??\tabcellsep \multicolumn{4}{l}{The number of windows and hence number}\\
\tabcellsep \multicolumn{4}{l}{of acknowledgements used in the existing}\\
\tabcellsep \multicolumn{3}{l}{slow-start and AIMD technique}\\
?? ??\tabcellsep \multicolumn{4}{l}{The number of windows and hence number}\\
\tabcellsep \multicolumn{4}{l}{of acknowledgements used in the}\\
\tabcellsep \multicolumn{4}{l}{proposed Unexpected Packet based}\\
\tabcellsep \multicolumn{3}{l}{Congestion Control technique}\\
?? ??\tabcellsep \multicolumn{4}{l}{The total time required to transmit an}\\
\tabcellsep \multicolumn{4}{l}{application in the existing slow-start and}\\
\tabcellsep \multicolumn{2}{l}{AIMD technique}\tabcellsep \\
?? ??\tabcellsep \multicolumn{4}{l}{The total time required to transmit an}\\
\tabcellsep \multicolumn{4}{l}{application in the proposed Unexpected}\\
\tabcellsep Packet\tabcellsep based\tabcellsep Congestion\tabcellsep Control\\
\tabcellsep technique\tabcellsep \tabcellsep \\
W\tabcellsep \multicolumn{2}{l}{Window size}\tabcellsep \\
W s\tabcellsep \multicolumn{2}{l}{Window start}\tabcellsep \\
\multicolumn{3}{l}{W end Window end}\tabcellsep \\
?\tabcellsep \multicolumn{2}{l}{Round trip time}\tabcellsep \\
?\tabcellsep \multicolumn{4}{l}{Time required to transmit consecutive}\\
\tabcellsep \multicolumn{2}{l}{packets in a window}\tabcellsep \end{longtable} \par
  {\small\itshape [Note: ? QoS: Quality of service (QoS)\hyperref[b1]{[2]} is the ability to provide different priority to different applications, users, or data flows i.e., it guarantees a certain level of performance to a data flow. Quality of service guarantees are important if the network capacity is insufficient, especially for real-time multimedia applications such as voice over IP, online games and IPTV, since these applications often require fixed bit rate and are delay sensitive. A best-effort network like Internet does not support quality of service.]} 
\caption{\label{tab_0}Table 1 :}\end{figure}
 			\footnote{© 2014 Global Journals Inc. (US)} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Shakkottai and Srikant ()]{b5}\label{b5} 	 		\textit{},  		 			Srinivas Shakkottai 		,  		 			R Srikant 		.  		 \xref{http://dx.doi.org/10.1561/1300000007}{10.1561/1300000007}.  	 	 		\textit{Network Optimization and Control, Foundations and Trendsin Networking}  		2007. 2008. 2  (3)  p. .  	 
\bibitem[Jin et al. (2002)]{b15}\label{b15} 	 		‘A Spectrum of TCP-friendly Windowbased Congestion Control Algorithms’.  		 			Shudong Jin 		,  		 			Liang Guo 		,  		 			Ibrahim Matta 		,  		 			Azer Bestavros 		.  		 ANI- 0095988.  	 	 		\textit{ANI-9986397, and ITR ANI-0205294, and bygrants from IBM, Sprint Labs, and Motorola Labs},  				July 2002.  		 			Boston University 		 	 	 (This work was supported in part by NSF grants CAREERANI-0096045) 
\bibitem[Jacobson (1988)]{b4}\label{b4} 	 		‘Congestion avoidance and control’.  		 			Jacobson 		.  	 	 		\textit{ACM Computer Communication Review}  		August 1988. 18 p. .  	 
\bibitem[Paxson et al. (1980)]{b12}\label{b12} 	 		‘Defense Advanced Research Projects 16’.  		 			V Paxson 		,  		 			M Allman 		,  		 			J Chu 		,  		 			M Sargent ; Postel 		,  		 			J 		.  	 	 		\textit{Request for Comments: 6298, Category: Standards Track},  				June 2011. January 1980. 760.  		 			Internet Engineering Task Force (IETF ; USC/Information Sciences Institute 		 	 	 (Internet Protocol) 
\bibitem[Defense Advanced Research Projects Agency (1981)]{b13}\label{b13} 	 		\textit{Defense Advanced Research Projects Agency},  		 RFC: 791.  		September 1981.  		 			University of Southern California 		 	 	 (INTERNET PROTOCOL) 
\bibitem[Constantine et al.]{b9}\label{b9} 	 		‘Framework for TCP Throughput Testing’.  		 			B Constantine 		,  		 			G Forget 		,  		 			R Geib 		,  		 			R Schrage 		.  	 	 		\textit{Internet Engineering Task Force (IETF), Request for Comments}  		 2070-1721.  		p. 6349.  	 
\bibitem[Steven et al. (2002)]{b6}\label{b6} 	 		\textit{Internet Congestion Control, IEEE Control Systems Magazine},  		 			H Steven 		,  		 			Fernando Low 		,  		 			John C Paganini 		,  		 			Doyle 		.  		February 2002.  	 
\bibitem[Welzl ()]{b1}\label{b1} 	 		\textit{Network Congestion Control, Managing Internet Traffic},  		 			Michael Welzl 		.  		2005. John Wiley \& Sons Ltd.  	 
\bibitem[Network Simulator ns-2]{b16}\label{b16} 	 		\textit{Network Simulator ns-2},  		 \url{http://www.isi.edu/nsnam/ns/}  		 	 
\bibitem[Abrantes and Ricardo (2005)]{b2}\label{b2} 	 		\textit{On Congestion Control for Interactive Real-time Applications in Dynamic Heterogeneous 4G Networks},  		 			Filipe Abrantes 		,  		 			Manuel Ricardo 		.  		March 17, 2005.  	 	 (This work was funded by the Portuguese Science and Technology Foundation) 
\bibitem[Pan et al. (2012)]{b0}\label{b0} 	 		‘PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem’.  		 			R Pan 		,  		 			P Natarajan 		,  		 			C Piglione 		,  		 			M Prabhu 		,  		 			V Subramanian 		,  		 			F Baker 		,  		 			B V Steeg 		.  	 	 		\textit{Cisco Systems}  		December 10, 2012.  	 	 (Internet Draft, draft-pan-tsvwg-pie-00 (work in progress) 
\bibitem[Floyd and Fall (1999)]{b3}\label{b3} 	 		‘Promoting the Use of End-to-End Congestion Control in the Internet, Networking’.  		 			S Floyd 		,  		 			K Fall 		.  	 	 		\textit{IEEE/ACM Transactions on}  		August 1999.  	 
\bibitem[Schulzrinne et al. (1996)]{b14}\label{b14} 	 		‘RTP: A Transport Protocol for Real-Time Applications’.  		 			H Schulzrinne 		,  		 			S Casner 		,  		 			R Frederick 		,  		 			V Jacobson 		.  	 	 		\textit{Request for Comments: 1889, Category: Standards Track},  				January 1996.  		 			Network Working Group 		 	 
\bibitem[Cheng (2010)]{b8}\label{b8} 	 		‘Seeding RTO with RTT sampled during three-way handshake’.  		 			Y Cheng 		.  	 	 		\textit{Intended status: Standard Updates: 3390, 2988, Creation date},  				June 30, 2010. January 2011.  	 	 (Google. IncInternet Draft, draft-ycheng-tcpm-rtosynrtt-00.txt) 	 (work in progress. Expiration date) 
\bibitem[Allman et al. (2009)]{b7}\label{b7} 	 		‘TCP Congestion Control’.  		 			M Allman 		,  		 			V Paxson 		,  		 			E Blanton 		.  	 	 		\textit{Request for Comments: 5681, Category: Standards Track},  				September 2009.  		 			Purdue University ; Network Working Group 		 	 
\bibitem[Forouzan]{b10}\label{b10} 	 		‘TCP/IP Protocol Suite’.  		 			B A Forouzan 		.  	 	 		\textit{Tata McGraw-Hill}  		 	 	 (3rd edition) 
\bibitem[Floyd et al. (2004)]{b11}\label{b11} 	 		‘The New Reno Modification to TCP's Fast Recovery Algorithm’.  		 			S Floyd 		,  		 			T Henderson 		,  		 			A Gurtov 		.  	 	 		\textit{Request for Comments: 3782, Category: Standards Track},  				April 2004.  		 			Network Working Group 		 	 
\end{bibitemlist}
 			 		 	 
\end{document}
