\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={TCP Performance Over Mobile IP Wired-cum-Wireless Networks},
 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{2012-05-15 (revised: 15 May 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-05-15}
\title{TCP Performance Over Mobile IP Wired-cum-Wireless Networks}
\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]{Dr. Md. Asif  Nashiry}

             \author[2]{Shauli Sarmin  Sumi}

             \author[3]{Subrata Kumar  Das}

             \affil[1]{  }

\renewcommand\Authands{ and }

\date{\small \em Received: 11 April 2012 Accepted: 3 May 2012 Published: 15 May 2012}

\maketitle


\begin{abstract}
        


Reliable transport protocol like TCP has served well the wired Internet where the packet losses are mainly due to congestion, but is not ready for Mobile IP wired-cum-wireless environments where the significant packet losses are due to bit errors and handoffs. In this paper, we have investigated the performance of TCP among the various TCP variants. We have observed both TCP senders (Newreno & Vegas) and TCP receivers (Base & Delayed-Ack). Using ns-2, we have evaluated the TCP throughput and packet delay over a single TCP connection. The simulation results suggest that a particular combination (one TCP sender with one TCP receiver) of TCP shows the best result in such Mobile IP networks.

\end{abstract}


\keywords{Wired-cum-Wireless Networks, TCP, Mobility, Mobile IP, Handoff}

\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
CP was basically developed assuming that it would run on wired networks. Wired networks usually have less bit error rates and hence less packet loss. Also, since mobility was not considered, there are no packet losses and delays caused by mobility. Hence, TCP was designed to assume that any segment loss is caused by the network congestion and on seeing any segment loss; TCP invokes its congestion control measures. In various circumstances wired and wireless networks are connected together to take the advantages of both. Usually, the wireless links have high bit error rates. Also, temporary disconnections occur because of the factors like channel fading, and handoffs when a mobile node is in motion. The handoff period depends on both the link level handoff protocol being used as well as the IP level handoff protocol being used, if any. The standard TCP implementations assume the cause of any packet loss to be the network congestion. Then, they reduce the congestion size to a minimum. Also, TCP invokes the slow-start mechanism. If the network links are slow, it takes long time to grow the congestion window. Thus, reduction in the size of the congestion window reduces the transmission rate and hence degrades the performance. Also, TCP undergoes a binary exponential backoff, causing long pauses of communication. Because of this, some time may be unused even after the mobile node recovers from the temporary disconnection. It has been observed that even a single wireless link can reduce the TCP performance considerably. In theory we can use existing transport protocols like TCP on a wireless host to communicate with a fixed network. Though this keeps the transport layer transparent to mobility, disconnection and other features of wireless and mobile hosts reduce the performance. Thus TCP proved not so efficient in Mobile IP wired-cum-wireless environments and suffers from performance degradation introduced by the conditions that exist in those environments. Hence, an optimized reliable transport protocol is very important for the development of the wireless Internet. This paper provides a realistic comparison of the performances of the various TCP variants over Mobile IP wired-cumwireless network. The TCP variants include both TCP senders (TCP Newreno and TCP Vegas) and TCP receivers (Base TCP Sink and Delayed-Ack TCP Sink). The reminder of this paper is organized as follows: Section 2 depicts the related works; mobile IP and TCP variants are described in Section 3. We define the simulation model in Section 4 and present the results and discussions in Section 5. The conclusion and future work follow in Section 6. 
\section[{II. RELATED WORKS}]{II. RELATED WORKS}\par
TCP/IP is the standard networking protocol stack for Internet. So it is expected to be deployed over wireless networks to allow seamless integration with the Internet. However, earlier research suggested that TCP performs poorly over cellular (single-hop) wireless networks \hyperref[b0]{(Holland \& Vaidya, 1999)}. A good amount of research has been done in the past to improve the performance of TCP in the conditions that prevail in mobile and wireless environments. Split connection approach is one of them. It separates TCP connection, one for the wireless network and the other for the wired network between a sender and a receiver. The motivation behind the use of separate connections is the fact that the characteristics of a wireless network are different from the characteristics of a wired network, hence a separate connection that is optimized to the kind of network it operates on, can be used. I-TCP \hyperref[b1]{(Bakre \& Badrinath, 1995)}, ELN \hyperref[b2]{(Balakrishnan \& Katz, 1998)} can be classified in this group.\par
Enhanced link layer approach is another solution. Since the basic factor that causes degradation in wireless environments is the nature of the transmission medium, an improvement in the link technology that operates over the physical layer can improve the overall performance. This was the idea behind enhanced link layer solutions. Mechanisms like ARQ, FEC \hyperref[b3]{(Chockalingam Zorzi \& Tralli, 1999)} were suggested to improve the performance at the lower layers which, in turn, can reduce the chances of TCP getting timed out and does not invoke its congestion control measures.\par
Most of the above-mentioned solutions require special support from the network infrastructure in some form or the other. Some other approaches were suggested that do not require any special support from the intermediate infrastructure and changes are confined to the end nodes. Path Prediction \hyperref[b4]{(Hadjiefthymiades, Papayiannis \& Merakos, 2002)} and ACK Regulator \hyperref[b5]{(Chan \& Ramjee, 2002)} come under this category. These solutions are not bound by the problem of encrypted traffic, and they do not assume any special support from the network infrastructure.\par
As suggested earlier, most related work focuses on to improve the TCP performance in wireless network. Also most of the earlier solutions (except ELN) try to optimize the mobile host acting as a TCP receiver but do not consider the case of a mobile TCP sender, which can also be a common case in the future. Also a few of the earlier work measured TCP performance with combining both the TCP senders and the TCP receivers. This paper provides a realistic comparison of performance of the various TCP variants over Mobile IP wired-cum-wireless network. The TCP variants include both TCP senders (TCP Newreno and TCP Vegas) and TCP receivers (Base TCP Sink and Delayed-Ack TCP Sink). 
\section[{III. MOBILE IP AND TCP VARIANTS}]{III. MOBILE IP AND TCP VARIANTS}\par
In order to achieve the mobility function, the Internet Protocol (IP) has extended to become the Mobile Internet Protocol (Mobile IP or MIP). Mobile IP provides hosts with the ability to change their point of attachment to the network without compromising their ability to communicate. The mobility support provided by Mobile IP is transparent to the other protocol layers so as not to affect the operation of applications which do not have the mobile capability.\par
Among various IP mobility proposals, Mobile IPv4 (Charles, 1996) \& \hyperref[b7]{(Perkins, 2002)} is the oldest and probably the most widely known mobility management proposal with IP. MIPv4 introduces three new entities required to support the protocol: the Home Agent (HA), the Foreign Agent (FA) and the Mobile Host (MH). Home and foreign agents are introduced for mobility management. Each time a mobile host connects to a network at a new location, it will obtain a temporary address, called Care-of Address (COA) from a foreign agent in the local network. Then the mobile host must inform its home agent of the new address by a registration procedure, which begins when the mobile host, possibly with the assistance of the foreign agent, sends a registration request with the COA. When the home agent receives this request, it may typically add the necessary information to its routing table, approve the request, and send a registration reply back to the mobile host.\par
A basic function of TCP is to provide reliable communication over an unreliable network layer. TCP ensures that the data is delivered from the sending process to the receiving process correctly and in order. TCP controls the traffic flow and network congestion by maintaining window (buffer to store data packets); and various TCP variants are classified according to the mechanism for maintaining this window. 
\section[{a) TCP New-Reno}]{a) TCP New-Reno}\par
A modification to Reno TCP called New-Reno TCP \hyperref[b8]{(Hoe, 1996)}. Since most TCP sessions last only for a short period of time, the initial slow start period is significant for the overall performance. A method is proposed to estimate an optimum slow start threshold (ssthresh) value by calculating the byte equivalent of bandwidth delay product of the network when a new connection is made. TCP New-Reno also deals with multiple packet losses from a single window. If two or more segments have been lost from the transmitted data (window), the Fast Retransmission and Fast Recovery algorithms will not be able to recover the losses without waiting for retransmission time out. New-Reno overcomes this problem by introducing the concept of a Fast Retransmission Phase, which starts on detection of a packet loss (receiving 3 duplicate ACKs) and ends when the receiver acknowledges reception of all data transmitted at the start of the Fast Retransmission phase.\par
The transmitter assumes reception of a partial ACK during the Fast Retransmission phase as an indication that another packet has been lost within the window and retransmits that packet immediately to prevent expiry of the retransmission timer. New Reno sets the congestion window (cwnd) to one segment on reception of 3 duplicate ACKs (i.e. when entering the Fast Retransmission Phase) and unacknowledged data are retransmitted using the Slow Start algorithm. The transmitter is also allowed to transmit a new data packet on receiving 2 duplicate ACKs. While the transmitter is in the Fast Retransmission Phase, it continues to retransmit packets using Slow Start until all packets have been recovered (without starting a new April retransmission phase for partial ACKs). Although this modification may cause unnecessary retransmissions, it reduces transmitter timeouts and efficiently recovers multiple packet loss using partial ACKs. b) TCP Vegas TCP Vegas \hyperref[b9]{(Brakmo \& Peterson, 1995)} does not involve any changes to the TCP specification; it is merely an alternative implementation that is able to interoperate with any other valid implementation of TCP. In fact, all the changes pare confined to the sending side. There are some techniques that Vegas employs to increase throughput and decrease losses.\par
It calculates the RTT more accurately. Using an accurate RTT estimate serves two purposes. First, it leads to a more accurate timeout calculation. Second, it is used in conjunction with the mechanism described next to decide to retransmit a dropped segment in a more timely fashion. It includes the new mechanism for deciding to retransmit Vegas treats the receipt of certain ACKs as a trigger to check if a timeout should happen. Moreover, Vegas only decreases the congestion window if the retransmitted segment was previously sent after the last decrease. Any losses that happened before the last window decrease do not imply that the network is congested for the current congestion window size, and therefore do not imply that it should be decreased again. Another most important feature of TCP Vegas is that the detection of congestion. Vegas calculates the expected throughput by: Expected = WindowSize / BaseRTT where WindowSize is the size of the current congestion window and BaseRTT is the RTT of a segment when the connection is not congested. It then calculates the current Actual throughput of the network. Then, Vegas compares Actual to Expected, and adjusts the window accordingly. 
\section[{c) Base TCP Sink}]{c) Base TCP Sink}\par
The base TCP sink object is responsible for returning ACKs to a peer TCP source object. It generates one ACK per packet received. The size of the ACKs may be configured. The creation and configuration of the TCP sink object is generally performed automatically by a library call. 
\section[{d) Delayed-Ack TCP Sink}]{d) Delayed-Ack TCP Sink}\par
A Delayed-Ack sink object is available for simulating a TCP receiver that ACKs less than once per packet received. This object contains a bound variable, which gives the number of seconds to wait between ACKs. The Delayed-Ack sink implements an aggressive ACK policy whereby only ACKs for in-order packets are delayed. Out-of-order packets cause immediate ACK generation. It is possible to configure the bound variable (interval) of the Delayed-Ack TCP Sink. 
\section[{IV. SIMULATION MODEL \& DESIGN}]{IV. SIMULATION MODEL \& DESIGN}\par
To design the Mobile IP wired-cum-wireless network topology we have considered various simulation parameters, which are supported by the network simulator-2 (NS-2) \hyperref[b10]{(Fall \& Varadhan, 2005)}. We have done simulation for two different topologies and call them topology 'A' and topology 'B' respectively. There is a roaming mobile node called Mobile Host (MH) that moves between its home agent and foreign agent in a certain velocity. Data will be exchanged (50,100), (200,300) and (500,300) respectively in the 700mX800m topology. In this network, the mobile node MH starts moving from position (50,100) at 10 sec towards destination (650,100) at fixed speeds (0, 5, 10, 15, 20, 25, or 30) m/s. After reaching the destination position (650,100), MH will stay there 1sec (pause time) and then again moves back to its initial starting position (50,100) at the same velocity. In this way, the mobile node MH changes its home agent (HA) and foreign agent (FA) several times depending upon its speed. We have used DSDV ad hoc routing protocol. FTP begins transferring packets of size 1000 bytes after 10 second.\par
Each wireless node has a buffer size of 50 packets.\par
Each simulation ends at 150 seconds.\par
There are fewer changes in Topology 'B'. We have used three base-station nodes in topology 'B' and call them Home Agent (HA), Foreign Agent-1 (FA1) and Foreign Agent-2 (FA2) respectively. The initial positions, (x,y), of the nodes MH, HA, FA1 and FA2 are (50,100), (200,300), (500,300) and (800,300) respectively in the 1000mX800m topology. In this case, simulation starts at 10 sec and ends at 190 sec. Here the mobile node MH starts moving from position (50,100) at 10 sec towards destination position (950,100) at a fixed speed of (0, 5, 10, 15, 20, 25, or 30) m/s while nodes HA, FA1 and FA2 serve as base station (gateway) nodes. As before, the pause time is 1 sec, that is, the mobile node MH will stay 1 sec at position (950,100) and then moves back to its initial position (50, 100) at the same velocity. Staying there 1 sec, it moves again towards the destination position. 
\section[{V. Performance analysis \& discussion}]{V. Performance analysis \& discussion}\par
This section describes a realistic analysis comparing the performance of the various TCP variants over multi-hop Mobile IP wired-cum-wireless networks. We have combined the TCP senders (New-Reno \& Vegas) with the TCP receivers (Base \& Delayed-Ack). We have considered the mobile node as a TCP sender. 
\section[{a) Throughput Analysis}]{a) Throughput Analysis}\par
We have evaluated the throughput for topology 'A' obtained with the TCP variants in terms of the total number of packets received at the destination node per unit time over intervals of 7 seconds for mobility 0 meter/sec, 15 meter/sec and 30 meter/sec and the results are plotted in figures.\par
From figure 2, we observe that after the initial connection establishment, all the variants achieve almost fixed throughput to the whole simulation time. It is common that if the window size increases, the throughput will also increase.  Among the four variants, Vegas to Delayed-Ack shows the best throughput. From figure 3 (a), it is seen that the throughput of each of the TCP variant decreases drastically. By comparing this figure to figure 2, it is observed that the throughput performance is worse in this case. From the start of the simulation to 35 seconds, throughput is the same (almost 700 kbps) as before (figure 2). But after 35 seconds it shows different result. The mobility of the mobile host is the cause of this degradation. In the case of figure 2, the mobile host remains stationary. But in this case the mobile host changes its base station for a number of times during simulation time. When changing base station a mobile host requires a handoff. The mobile host changes base station three times; so require three handoffs. And at the time of each handoff packets are dropped and throughput decreases.\par
Figure 3(b) shows the similar type of result except the throughput is reduced more times than that of figure 3(a). Since in this case, the mobility is 30 meter/sec, more handoff is required and at the time of each handoff throughput is reduced. One interesting feature which is observed from figures 3(a) and 3(b) is that during first handoff throughput performance decreases drastically but during the second, third and successive handoffs throughput decreases slightly. But in such an environment Vegas to Delayed-Ack performs well among the TCP variants. Its throughput reduces less than that of the others. Concentrating on the receiver portion in figure 2, 3(a) and 3(b), we see that the performance of the Base TCP receivers is lower than that of the Delayed-Ack TCP receivers; no matter whether the TCP sender is New-Reno or Vegas. Since all the terminals in Mobile IP network share the same radio channel to send and receive packets, the collision of data packets and acknowledgement (ACK) packets in the radio channel can severely reduce TCP throughput. But Delayed-Ack receiver employs less ACK packets. So, for transferring TCP data packets, TCP sender can utilize the channel more. Hence throughput of any TCP sender synchronized with Delayed-Ack receiver is better than that of TCP sender with Base receiver. Now with fixed Delayed-Ack receiver, we are going to observe the performance of New-Reno and Vegas sender. By evaluating the throughput from three different mobility scenarios it is seen that TCP Vegas sender performs well. As stated earlier, TCP Vegas estimates the network status to adjust its window value. This property enriches its performance in such a heterogeneous environment.\par
We also average the throughput over the simulation duration and plot the average throughput obtained with the TCP variants as a function of node mobility for both topology 'A' and 'B' in figure 4 and figure 5 respectively.\par
According to figure 4 and 5, when the source node is stationary (node mobility 0 meter/sec), all the TCP variants achieve their own highest throughputs in both topology 'A' and topology 'B', because of occurring no handoffs in this situation.\par
The throughputs achieved with New-Reno to Base TCP and Vegas to Base TCP are lower than those achieved with New-Reno to Delayed-Ack TCP and Vegas to Delayed-Ack TCP in both topology 'A' and topology 'B'. It is due to the fact that ACKs and TCP packets share the same channel; so decreasing the ACKs by using the Delayed-Ack receiver instead of Base receiver it is possible to improve the throughput of TCP.    The delay performance of Vegas to Delayed-Ack TCP and Vegas to Base TCP is relatively similar and they show low delay in all the mobility so they show relatively similar and high packet delivery ratio in both the topologies. Since the average delay of Vegas to Delayed-Ack TCP is low it has given a very good throughput in the simulation time in both topologies. 
\section[{Vi. Conclusion and future works}]{Vi. Conclusion and future works}\par
While TCP is needed for a Mobile IP network, the current variants of TCP are not adequate for the task. To achieve good TCP performance in Mobile IP wired-cum-wireless networks a variety of solutions have been proposed and in most of the solutions the mobile node acts as a TCP receiver. However, little attention has been paid to study the performance of TCP traffic over combining both TCP senders and receivers. We have investigated the performance of TCP over combining both TCP senders (Newreno \& Vegas) and TCP receivers (Base \& Delayed-Ack) using simulations in ns-2 for a range of node mobility with a single traffic source. The performance metrics that we have considered include TCP throughput and packet delay. On throughput performance, Vegas TCP to Delayed-Ack gains the best performance. On the sender side, the effective congestion control technique of Vegas makes it optimal in such a heterogeneous environment. And in the receiver side, the Delayed-Ack receiver makes the proper use of channel by sending fewer ACK packets.\par
We have also evaluated throughput with respect to node mobility. The result shows that throughput of each TCP variant varies similarly with respect to each other against mobility of node. But Vegas to Delayed-Ack shows the best result as compared with other variants. Delay performance of each variant shows the confidential result. TCP Vegas has the lowest delay no matter whether the receiver is Base or Delayed-Ack. New-Reno has large delay. But among them New-Reno to Delayed-Ack has the highest delay. After observing packet delivery ratio and delay, it is seen that the variant that gains highest packet delivery ratio has lowest delay. Though all the variants of TCP suffer in Mobile IP wiredcum-wireless networks, it is clear from the various results that if we use Vegas TCP as a source (sender) and Delayed-Ack as a sink (receiver), then this combination shows the best result among the all TCP variants. Next, we plan to investigate the performance of all the TCP variants with multiple traffic sources in more complex heterogeneous networks and also consider some link layer and network layer feedbacks to improve their performance. \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Figure 1 :}\end{figure}
      \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.4348837209302326\textwidth}P{0.4151162790697674\textwidth}}
Newreno to Base\tabcellsep Newreno to Delayed-Ack\\
Vegas to Base\tabcellsep Vegas to Delayed-Ack\\
(kbps)\tabcellsep \\
Throughput\tabcellsep \end{longtable} \par
  {\small\itshape [Note: accurate RTT estimates, Vegas leads to a more accurate timeout calculation. This is why Vegas shows very low delay as compared to New-Reno. The average delay of New-Reno to Delayed-Ack is the worst among all the variants. This is why it has given the lowest packet delivery ratio. The average delay of New-Reno to Base is better than that of New-]} 
\caption{\label{tab_0}}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XII Issue IX Version I} 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{© 2012 Global Journals Inc. (US)} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Holland and Vaidya ()]{b0}\label{b0} 	 		‘Analysis of tcp performance over mobile ad hoc networks’.  		 			G Holland 		,  		 			N Vaidya 		.  	 	 		\textit{Proceedings of ACM Mobicom},  				 (ACM Mobicom)  		1999. p. .  	 
\bibitem[Balakrishnan and Katz ()]{b2}\label{b2} 	 		‘Explicit Loss Notification and Wireless Web Performance’.  		 			H Balakrishnan 		,  		 			R Katz 		.  	 	 		\textit{Proceedings of IEEE Globecom Internet Mini-Conference},  				 (IEEE Globecom Internet Mini-ConferenceSydney, Australia)  		1998.  	 
\bibitem[Bakre and Badrinath ()]{b1}\label{b1} 	 		‘I-TCP: Indirect TCP for Mobile Hosts’.  		 			A Bakre 		,  		 			B R Badrinath 		.  	 	 		\textit{Proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS)},  				 (the 15th International Conference on Distributed Computing Systems (ICDCS))  		1995. p. .  	 
\bibitem[Hoe ()]{b8}\label{b8} 	 		‘Improving the start-up behavior of a congestion control scheme for TCP’.  		 			J Hoe 		.  	 	 		\textit{ACM SIGCOMM},  				1996.  	 
\bibitem[Fall and Varadhan ()]{b10}\label{b10} 	 		\textit{ns Notes and Documentation},  		 			K Fall 		,  		 			K Varadhan 		.  		 \url{http:/www-mash.cs.Berkeley.edu/ns/}  		2005. 28.  		 			Lawrence Berkeley National Laboratory 		 	 
\bibitem[Perkins and Charles ()]{b6}\label{b6} 	 		 			E Perkins 		,  		 			Charles 		.  		\textit{IP Mobility Support. RFC},  				1996. 2002.  	 
\bibitem[Perkins ()]{b7}\label{b7} 	 		 			C Perkins 		.  		 IETF RFC 3344.  		\textit{IP mobility support for IPv4},  				2002.  	 
\bibitem[Brakmo and Peterson ()]{b9}\label{b9} 	 		‘TCP Vegas: End to End Congestion Avoidance on a Global Internet’.  		 			L S Brakmo 		,  		 			L L Peterson 		.  	 	 		\textit{IEEE Journal on Selected areas in Communications}  		1995. 13  (8)  p. .  	 
\bibitem[Chan and Ramjee ()]{b5}\label{b5} 	 		‘TCP/IP Performance over 3G Wireless Links with Rate and Delay variation’.  		 			M C Chan 		,  		 			R Ramjee 		.  	 	 		\textit{Proceedings of MOBICOM},  				 (MOBICOM)  		2002.  	 
\bibitem[Hadjiefthymiades et al. ()]{b4}\label{b4} 	 		\textit{Using Path Prediction to Improve TCP Performance in Wireless/Mobile Communications},  		 			S Hadjiefthymiades 		,  		 			S Papayiannis 		,  		 			L Merakos 		.  		2002. IEEE Communication Magazine.  	 
\bibitem[Chockalingam et al. ()]{b3}\label{b3} 	 		‘Wireless TCP Performance with Link Layer FEC/ARQ’.  		 			A Chockalingam 		,  		 			A Zorzi 		,  		 			V Tralli 		.  	 	 		\textit{Proceedings of IEEE ICC'99},  				 (IEEE ICC'99)  		1999. p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
