\documentclass[journal]{IEEEtran}
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[journal]{../sty/IEEEtran}

% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.


% *** CITATION PACKAGES ***
%
\usepackage{cite}
% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
   \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
   \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
   \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
   \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
   \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
   \DeclareGraphicsExtensions{.eps}
\fi

%\usepackage{array}
%\usepackage[cmex10]{amsmath}
\usepackage[]{caption}
%\usepackage{algorithm}
%\usepackage[lined,boxed,commentsnumbered]{algorithm2e}
\usepackage[ruled, vlined, linesnumbered]{algorithm2e}
\usepackage{algorithmic}
\usepackage[font=footnotesize]{subfig}
\usepackage{pbox}
\usepackage[fleqn]{amsmath}

% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}

%\usepackage{setspace}
%\textbf{•}\doublespacing

\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
% Do not put math or special symbols in the title.
\title{A Router-aided P2P Traffic Localization Method with Bandwidth Limitation}
%
%
% author names and IEEE memberships
% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
% a structure at a ~ so this keeps an author's name from being broken across
% two lines.
% use \thanks{} to gain access to the first footnote area
% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
% was not built to handle multiple paragraphs
%

\author{Hiep Hoang-Van, Takumi Miyoshi,~\IEEEmembership{Member,~IEEE,}
        and Olivier Fourmaux,~\IEEEmembership{Member,~IEEE}% <-this % stops a space
\thanks{H. Hoang-Van and T. Miyoshi are with the Graduate School of Engineering and Science, Shibaura Institute of Technology, Saitama-shi, Saitama, 337-8570 Japan.}% <-this % stops a space
\thanks{O. Fourmaux is with the Laboratoire d'Informatique de Paris 6, UPMC Sorbonne Universit\'{e}s, Paris, 75005 France.}% <-this % stops a space
\thanks{Manuscript received ???; revised ???.}}

% note the % following the last \IEEEmembership and also \thanks - 
% these prevent an unwanted space from occurring between the last author name
% and the end of the author line. i.e., if you had this:
% 
% \author{....lastname \thanks{...} \thanks{...} }
%                     ^------------^------------^----Do not want these spaces!
%
% a space would be appended to the last name and could cause every name on that
% line to be shifted left slightly. This is one of those "LaTeX things". For
% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
% "AB" then you have to do: "\textbf{A}\textbf{B}"
% \thanks is no different in this regard, so shield the last } of each \thanks
% that ends a line with a % and do not let a space in before the next \thanks.
% Spaces after \IEEEmembership other than the last one are OK (and needed) as
% you are supposed to have spaces between the names. For what it is worth,
% this is a minor point as most people would not even notice if the said evil
% space somehow managed to creep in.



% The paper headers
\markboth{Journal of Computer Science and Communication Engineering,~Vol.~xx, No.xx, xxxx~20xx}%
{Shell \MakeLowercase{\textit{H. Hoang-Van et al.}}: A Hierarchical P2P Traffic  Localization Method with Bandwidth Limitation}
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.
% 
% *** Note that you probably will NOT want to include the author's ***
% *** name in the headers of peer review papers.                   ***
% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
% you desire.




% If you want to put a publisher's ID mark on the page you can do it like
% this:
%\IEEEpubid{0000--0000/00\$00.00~\copyright~2012 IEEE}
% Remember, if you use this you must call \IEEEpubidadjcol in the second
% column for its text to clear the IEEEpubid mark.



% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle

% As a general rule, do not put math, special symbols or citations
% in the abstract or keywords.
\begin{abstract}
Recently, peer-to-peer (P2P) systems generate a large amount of unwanted cross-domain traffic on the Internet due to a lack of knowledge about physical network topology. The unwanted cross-domain traffic is especially costly for the internet service providers (ISPs). To reduce the cross-ISP/AS (autonomous system) traffic, the existing approaches introduce network-aware strategies in which a lot of modifications of P2P systems are required. In particular, each P2P application must be modified to integrate with a locality-aware procedure and/or a communication protocol to obtain the topological information from an ``oracle" server. In this paper, we propose two schemes for localizing P2P traffic without any peer reaction: (1) fixed-length bandwidth limitation scheme, (2) hierarchical bandwidth limitation scheme. By intentionally limiting the bandwidth of each connection path between peers based on geographical location of the peers’ destinations, the traffic can be localized with single level for the first scheme and with multiple levels for the second scheme. Compared to the existing locality-enhancing approaches, our two schemes require neither dedicated servers, nor cooperation between ISPs and users, nor any modification of existing P2P application software. Therefore, we believe that all types of P2P applications can easily utilize our proposals. Experiments on P2P streaming applications indicate that the fixed-length bandwidth limitation scheme successfully realizes P2P traffic localization. Moreover, the hierarchical bandwidth limitation scheme not only significantly reduces the cross AS/ISP traffic but also maintains a good performance of P2P applications.  
\end{abstract}

% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
P2P, router-aided approach, hierarchical traffic localization, bandwidth limitation.
\end{IEEEkeywords}

% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
% The very first letter is a 2 line initial drop letter followed
% by the rest of the first word in caps.
% 
% form to use if the first word consists of a single letter:
% \IEEEPARstart{A}{demo} file is ....
% 
% form to use if you need the single drop letter followed by
% normal text (unknown if ever used by IEEE):
% \IEEEPARstart{A}{}demo file is ....
% 
% Some journals put the first two words in caps:
% \IEEEPARstart{T}{his demo} file is ....
% 
% Here we have the typical use of a "T" for an initial drop letter
% and "HIS" in caps to complete the first word.
\IEEEPARstart{M}{ost P2P} applications form overlay networks for communicating among peers on top of the physical network topology. However, the overlay is often established based on the resource availability and thus largely independent from the underlay network topology. As a result, P2P systems generate a large quantity of unwanted traffic on the Internet. In particular, the unwanted cross-domain traffic proves to be costly for the ISPs. Therefore, the ISPs or network operators often manage P2P traffic by bandwidth throttling or limiting and/or even blocking P2P systems in their network. On the contrary, the P2P systems try to hide them from the network by changing their design, e.g., applying dynamic port strategies. It is more challenging to recognize the P2P traffic. In addition, blocking P2P systems would reduce sharply the demand of end users, who have family with using some P2P applications. Therefore, the fundamental concern of the ISPs is essentially not to block, but to turn the inter-ISP/AS traffic into the intra-domain traffic. 

To address the problem, a variety of methods have been proposed, and many works confirmed that the consideration of peer location would reduce the cross-domain traffic as well as conserve the bandwidth. However, almost all of existing approaches solve the problem on the application layer. Therefore, P2P systems must be essentially equipped with a locality-aware neighbor peer-selection mechanism to realize traffic localization. This can be achieved by one of the following ways:  
\begin{itemize}
\item{The enhancement of trackers to efficiently gather information of the underlay network. On the P2P applications side, they need to implement an appropriate protocol to communicate with the enhanced trackers.}
\item{The modification of the P2P application software to upgrade from the current neighbor peer-selection mechanisms to locality-aware ones. Because P2P applications currently only employ random and/or round-trip time (RTT)-based strategies.} 
\item{Or both of the above.}
\end{itemize}
Several modifications of P2P systems are inevitable as described above.

In this paper, we introduce a novel approach to localize P2P traffic without any modification of existing application software. We exploit an important feature of P2P applications that a querying peer will select a candidate peer as its neighbor if the candidate peer is likely to provide better performance. For instance, the querying peer tends to select a candidate peer who has shorter RTT than others. Since the network performance is affected by various factors, communication with peers across network domains is sometimes better than the local communication. This leads to the increasing of cross-domain traffic. Based on this observation, if we intentionally degrade the quality of connection paths of inter-domain traffic, the querying peer will tend to remove the inter-domain connections and select the local connections instead. In other words, we can turn the inter-domain traffic into the intra-domain traffic. To achieve this, we propose to limit the bandwidth of the inter-domain traffic at network routers.

We propose two different schemes: (1) fixed-length bandwidth limitation scheme; (2) hierarchical bandwidth limitation scheme. In the first scheme, the bandwidth of all the connections to foreign peers will be limited with a constant value. This scheme is to demonstrate the effectiveness of the bandwidth limitation in traffic localization problem. In the second scheme, the traffic can be hierarchically localized with multiple levels of localization such as inside an AS, inside an ISP, or inside a country. The value of limited bandwidth should depend on both the physical distance between peers and the number of peers exists in the same area as the querying peer. The first factor ensures that lower bandwidth will be allocated for farther peers than closer ones, whereas the second factor realizes our hierarchical feature of localization. In particular, we first try to localize the traffic at AS level if some candidate peers exist inside the same AS. We will change from AS level to ISP and country level if no candidate peer exists in the same AS and ISP, respectively.  Since our proposal is deployed on network routers – outside of the peers, it is completely independent of P2P applications, and thus requires neither dedicated servers, nor collaboration between ISPs and P2P users, nor modification of application software.  Therefore, the proposal can be easily applied to all P2P applications.

The remainder of this paper is organized as follows. In Section II, we discuss about the related work. Section III describes two proposed schemes for hierarchical traffic localization, and Section IV then shows the implementation two schemes. The experimental results are presented in Section V. Finally, Section VI provides conclusions and our future work.

\section{Relate Work}
Overprovisioning and deep packet inspection (DPI)-based bandwidth management are considered the best conventional strategies to deal with P2P traffic \cite{Dunaytsev2012}. However, they do not solve the fundamental concern of the ISPs, which is to reduce the cross-domain traffic, i.e., to localize the traffic. The idea of P2P traffic localization was first introduced by Karagiannis et al., who studied BitTorrent trace logs and found that about 50 percent of the files could be downloaded from peers at the same ISP if a locality-aware peer-selection mechanism is used \cite{Karagiannis2005}. Plissonneau et al. analyzed eDonkey file sharing system, and reported that most of traffic traversed nationwide or international networks, in which 40 percent of the traffic could be localized \cite{Plissonneau2006}.

Aggarwal et al. proposed a solution to build up a relationship between ISPs and P2P users \cite{Aggrarwal2007}. ISPs maintain an ``oracle’’ service to help P2P users in selecting their neighboring peers. When a P2P user sends a list of possible neighbors to the oracle, the oracle ranks them according to certain criteria such as high bandwidth links, low latency, or closer peers, etc. Although the oracle can be introduced into the network independently of the P2P applications, this scheme requires a dedicated server as well as a good cooperation between ISPs and P2P users. In addition, each P2P application must be modified to add an additional protocol to communicate with the oracle.  

P4P is a famous framework that follows the oracle idea \cite{Xie2008}. In P4P, ISPs maintain iTrackers in their own networks. The iTrackers provide the p-distance interface, representing the logical distance between each pair of PIDs (aggregation nodes). There are several dimensions for the ISPs to control the p-distance information. From the P2P applications side, they can obtain the necessary information for neighbor peer selection directly from the iTrackers or indirectly via appTrackers. Recently, the Internet Engineering Task Force (IETF) has standardized a query/respond protocol for the oracle-based system in rfc5693 and rfc6708, known as Application Layer Traffic Optimization (ALTO) \cite{Seedorf2009,RAlimi2011}. Although the ALTO approaches improve not only the network efficiency but also the P2P application performance, they require dedicated servers and several modifications of existing P2P application software.

Choffnes and Bustamante proved that the presence of the oracle service provided by ISPs is redundant because the content distributed networks (CDNs) have already gathered all necessary information \cite{Choffnes2008}. By using CDN’s DNS redirection, they hypothesized that two peers are recognized as close to each other if they are sent to a similar set of replica servers. This idea is implemented as a java plugin to Azureus BitTorrent client, named ``Ono’’. This method requires support from many subscribing peers installing Ono plugin distributed worldwide. Furthermore, to apply this method for other types of P2P applications such as P2P streaming applications (P2PTV), we believe that some modifications must be required.

Bindal et al. proposed biased neighbor-selection scheme applying for BitTorrent in which a peer selects only \textit{k} peers from outside of the ISP, and the majority peers within the same ISP as itself, where \textit{k} is a parameter \cite{Bindal2006}. This biased neighbor-selection scheme successfully reduces inter-domain traffic while maintain the near-optimal performance of the BitTorrent, i.e., it realizes a win-no lose situation. The authors also introduced two ideas for implementing the biased neighbor selection: (1) the enhancement of trackers and clients and (2) the use of P2P traffic shaping devices. The former certainly requires a lot of software modification, whereas the latter requires no modification of trackers or clients but does require knowing the peer list format sent from the trackers. In other words, the method depends on the P2P applications.

Lee and Nakao introduced another approach for traffic localization applying to BitTorrent, called Netpherd, which is independent of the application \cite{Lee2013,Lee2012}. Netpherd tries to enable local peers to communicate with each other by adding artificial delay into the inter-domain traffic. The idea of degrading network performance of inter-domain connections is similar to our work. However, they focused on BitTorrent, a file sharing system. Moreover, Netpherd only localizes the traffic at AS level because the delay length is constant for all inter-AS traffic, e.g., 100 ms.

We previously proposed P2P-DISTO for P2P traffic localization without any peer reaction, which focused on P2PTV services \cite{Miyoshi2012}. P2P-DISTO inserts an additional delay into each P2P packet according to geographical locations of peers. The delay length is constant for all foreign traffic, e.g., 500 ms or 1000 ms, P2P-DISTO thus only realizes traffic localization at country level. In this study, we proceed to follow P2P-DISTO but use a different mechanism. We limit the bandwidth of the inter-domain traffic instead of inserting delay. In addition, we extend the scope of localization from single level to multiple levels.

\section{Proposed Schemes}
According to the report of Cisco System Inc. \cite{CiscoReport2112}, the P2P traffic is on the declining in percentage of overall Internet traffic due to the degradation of P2P file sharing systems. However, it is still increasing rapidly in volume with tremendous growing of video streaming services. Therefore, our goal is to realize traffic localization focusing on P2PTV services, which are predicted to be much more popular in the very near future. Thus, currently, P2PTV applications such as PPTV (update version of PPLive) \cite{PPTV}, PPStream \cite{PPStream}, SopCast \cite{SopCast}, Zattoo \cite{Zattoo} have become increasingly popular.

The majority of existing P2PTV applications implements RTT-based peer-selection mechanism. In particular, P2PTV tends to eliminate worse connections based on the RTT measured before starting downloads the data pieces. From this observation, we proposed two different schemes based on bandwidth limitation. Since the RTT information can be changed by limiting the bandwidth, we influence the neighbor peer selection of P2PTV indirectly.  

Given a querying peer, $\mbox{peer}_0$, and a list of $N$ candidate peers, \{$\mbox{peer}_1, \mbox{peer}_2, ..., \mbox{peer}_N$\}, let ($\mbox{as}_0, \mbox{isp}_0, \mbox{cc}_0$) be denoted AS number, ISP name, and country code of the querying peer, respectively, and ($\mbox{as}_i, \mbox{isp}_i, \mbox{cc}_i$) be denoted AS number, ISP name, and country code of $\mbox{peer}_i$, respectively. Our goal is to compute the limited bandwidth assigned to a candidate $\mbox{peer}_i$.

\subsection{Fixed-length bandwidth limitation scheme}
To prove the effectiveness of bandwidth limitation method in P2P traffic localization problem. We first introduce fixed-length bandwidth limitation scheme. Figure \ref{fig:the_proposed_concept_1} presents the concept of the scheme. The scheme does nothing with local traffic inside the same country as the querying peer, but limits the bandwidth of traffic that goes out to or come in from different countries. In other words, the bandwidth of connections with foreign peers is forced to be much lower than that of local ones. The RTTs of the foreign peers is thus increased. The querying peer will then prefer to connect with local neighboring peers that have shorter RTTs. 

The limited bandwidth assigned to a candidate $\mbox{peer}_i$ is computed by [kbps], as follows:
\begin{eqnarray}
\label{eq6}
\mbox{bw}_i = f(\mbox{cc}_i, \mbox{cc}_0) = \left\{\begin{array}{ll}
+\infty, & \mbox{if } \mbox{cc}_i = \mbox{cc}_0 \\ C, & \mbox{if } \mbox{cc}_i \not= \mbox{cc}_0
\end{array}
\right.
\end{eqnarray}
where $C$ is a constant number.
    
\subsection{Hierarchical bandwidth limitation scheme}
Localizing the traffic at country level only is surely not enough in real situation. We therefore introduce a hierarchical bandwidth limitation scheme for localizing traffic hierarchically with multiple levels. Figure \ref{fig:the_proposed_concept} illustrates the concept of the scheme at AS level. We do nothing with local traffic within the same AS, but limit the bandwidth of the traffic that goes out to or comes in from different ASes, ISPs, or countries. For farther peers, a lower bandwidth is allocated than closer ones. We will change from AS level to ISP and country level if no candidate peer exists in the same AS and ISP, respectively. The behavior of the ISP level is as follows: do nothing with the traffic within the same ISP, but limit the bandwidth of the traffic that goes out to or comes in from different ISPs, or countries. Similarly, for the country level, we do nothing with the traffic inside the country but limit the bandwidth of oversea traffic.

To realize the concept of hierarchical traffic localization mentioned above, we propose a logical distance representing a distance adjustment factor between a candidate peer and the querying peer. The logical distance between $\mbox{peer}_i$ and $\mbox{peer}_0$ is defined as follows:
\begin{eqnarray}
\label{eq1}
D_i &=& f_1(\mbox{as}_i,\mbox{as}_0) e^{-\frac{1}{n_1+\varepsilon}} + f_2(\mbox{isp}_i,\mbox{isp}_0) e^{-\frac{1}{n_2+\varepsilon}} \nonumber \\
&&+ f_3(\mbox{isp}_i, \mbox{cc}_i, \mbox{isp}_0, \mbox{cc}_0)e^{-\frac{1}{n_3+\varepsilon}},
\end{eqnarray}
\mathindent=7mm
where $n_1$, $n_2$, and $n_3$ are the total numbers of peers in the same AS, ISP, and country as $peer_0$, respectively, $\varepsilon$ is a very tiny constant to ensure the denominators of all fractions never come to zero, and
\mathindent=5mm
\begin{eqnarray}
f_1(\mbox{as}_i, \mbox{as}_0) &=& \left\{\begin{array}{ll}
0, & \mbox{if } \mbox{as}_i = \mbox{as}_0 \\ \theta_1, & \mbox{if } \mbox{as}_i \not= \mbox{as}_0
\end{array} 
\right.
\label{eq2} \\
f_2(\mbox{isp}_i, \mbox{isp}_0) &=& \left\{\begin{array}{ll}
0, & \mbox{if } \mbox{isp}_i = \mbox{isp}_0 \\ \theta_2, & \mbox{if } \mbox{isp}_i \not= \mbox{isp}_0
\end{array} 
\right.
\label{eq3}
\end{eqnarray}
\mathindent=0mm

$f_3(\mbox{isp}_i, \mbox{cc}_i, \mbox{isp}_0, \mbox{cc}_0)$

\setlength{\arraycolsep}{0.0em}
\begin{eqnarray}
= 
\left\{\begin{array}{ll}
0, & \mbox{if } \mbox{isp}_i = \mbox{isp}_0 \\ 
d(\mbox{peer}_i, \mbox{peer}_0), & \mbox{if } \mbox{isp}_i \not= \mbox{isp}_0, \\ & \mbox{and } \mbox{cc}_i = \mbox{cc}_0 \\
\theta_3 + d(\mbox{peer}_i, \mbox{peer}_0), & \mbox{if } \mbox{cc}_i \not= \mbox{cc}_0
\label{eq4}
\end{array} 
\right.
\end{eqnarray}

\mathindent=7mm

\begin{figure}[t]
\centering
\includegraphics[width=0.45\textwidth]{JCSCE2014_the_concept_1.eps}
\caption{The concept of fixed-length bandwidth limitation scheme.}
\label{fig:the_proposed_concept_1}
\end{figure}

Since ISPs, including ASes, have to manage their own networks, the information that the querying peer connects to a peer exists inside or outside the AS/ISP is the most important. Hence, $\theta_1$ and $\theta_2$ are coefficients to differentiate the inter-AS/ISP traffic from the intra-AS/ISP traffic, respectively. To ensure that the logical distances of farther peers will be higher than those of closer ones, we define $d(\mbox{peer}_i, \mbox{peer}_0)$ as the physical distance between $\mbox{peer}_i$ and $\mbox{peer}_0$. Even though some nearby physical locations might be far apart from each other in terms of network connectivity in some specific cases, the physical distance is still a reasonable estimation in most cases. The coefficient, $\theta_3$, is to make the distances of foreign peers sufficient higher than those of local ones.

Since lower bandwidth should be allocated for farther peers, we compute the limited bandwidth for a candidate $peer_i$ as follows:
\begin{eqnarray}
\label{eq5}
\mbox{bw}_i = \frac{1}{\mbox{D}_i + \varepsilon_1} \times \mbox{B}  & \mbox{[kbps]},
\end{eqnarray}
where B is a bandwidth unit, and $\varepsilon_1$ is a tiny constant to ensure the denominator of the fraction never come to zero.

\begin{figure}[t]
\centering
\includegraphics[width=0.45\textwidth]{JCSCE2014_the_concept.eps}
\caption{The concept of hierarchical bandwidth limitation scheme.}
\label{fig:the_proposed_concept}
\end{figure}

From above equations, we defined the allocated bandwidth of a candidate peer based on not only the physical distance but also the number of peers in the same area as the querying peer. This enables our method to realize the hierarchy of localization. For instance, if no candidate peer exists in the same AS or ISP, i.e., $n_1 = n_2 = 0$, the first two exponential functions in Eq.\ (\ref{eq1}) will come to zero, the logical distance will therefore depend only on the country information. In the worst case, if no candidate peer exists in the same country as the querying peer, $n_1 = n_2 = n_3 = 0$, the logical distance will be almost zero; the limited bandwidth for every peer in Eq.\ (\ref{eq5}) will go to $+\infty$, which means that no bandwidth limitation is applied. Therefore, the proposed method will not affect the performance of P2P applications even when no local peer exists.

\subsection{Proposed router architecture}
We introduce a router-aided approach to implement the proposed method independently of the P2P applications. Figure \ref{fig:router_architecture} shows the architecture of the router. Three modules, a traffic classification, location identifier, and bandwidth limitation module, are added into a common router. The traffic classification module classifies the input traffic into P2P or non-P2P traffic. To avoid the degradation of service quality of non-P2P applications, the non-P2P traffic goes directly to the common router function. In the location identifier, the destination IP address of every P2P packet is first examined. The identifier then resolves the location information of the destination by using several IP-to-geographic-location database services. According to this geographical location information, the bandwidth limitation module limits the bandwidth of connection between the querying peer and the candidate peer. The limited bandwidth for each peer is computed according to Eqs.\ (\ref{eq6}) and (\ref{eq5}) for the fixed-length bandwidth limitation scheme and the hierarchical bandwidth limitation scheme, respectively.

\section{Implementation of Proposed Method}
To implement the proposed router, we set up a PC-based router equipped with an Intel Core i7-2600 3.4 GHz CPU, 12 GB of DDR3 memory, and two 1 Gbps Ethernet network interface cards, operated under Linux Ubuntu 12.04 with 3.2.0-29 generic kernel.

In the research field of traffic classification, there are many methods that have been previous proposed. For instance, to block P2P traffic, ISPs usually apply deep packet inspection and session-based classification with 5 tuples (IP addresses, port numbers, and protocol type). In our previous work, we could easily check the peer list format of some P2P streaming applications because the peer list were sent in clear text without any encoding \cite{hiephvSNPD2013}. Therefore, all traffic transferred with the peers existing in the peer list can be recognized as P2P traffic. Recently, an accurate behavioral classification method for P2P traffic, named ``Abacus”, has been proposed \cite{Valenti2011}. Abacus relies only on the count of packets and bytes that peers exchange during small fixed-length time windows. Therefore, we can utilize such type of the above methods to implement the traffic classification module in our router. In this study, however, we assume that such the classification module is beyond the scope of this paper, and thus focus only on the implementation of bandwidth limitation module to verify the effectiveness of traffic localization in a real network.

\begin{figure}[t]
\centering
\includegraphics[width=0.35\textwidth]{JCSCE2014_router_architecture.eps}
\caption{The proposed router architecture.}
\label{fig:router_architecture}
\end{figure}

The bandwidth limitation module is implemented in the following main steps:
\begin{itemize}
\item{\textit{Packet monitoring}: we use {\tt libpcap}, a well-known packet capture library to examine all packets going through the router \cite{libpcap}. The headers of the packets are checked to read their source and destination IP addresses.}
\item{\textit{IP-to-location mapping}: the locations of the obtained IP addresses are then resolved by using IP-to-location services. In this implementation, we use GeoLite database services including GeoLite ASN, GeoLite City, and GeoLite Country, which are free IP geolocation databases created by MaxMind \cite{MaxMind2012}.}
\item{\textit{Computation of logical distance and limited bandwidth value}: The limited bandwidth for each candidate peer is computed according to Eqs.\ (\ref{eq6}) and (\ref{eq5}) for the fixed-length bandwidth limitation scheme and the hierarchical bandwidth limitation scheme, respectively.}
\item{\textit{Bandwidth limitation}: for the bandwidth limitation, we utilize {\tt dummynet}, a flexible tool for simulating packet filtering, bandwidth management, packet delay, and packet loss \cite{dummynet}. By changing the configuration of {\tt ipfw} firewall, a user interface provided by {\tt dummynet}, we can easily setup many pipes between sender and receiver peers. All the packets will be carried in these pipes. Each pipe can be configured with a different bandwidth value computed from the previous step.}
\end{itemize}

\begin{algorithm}[t]
	\begin{footnotesize}
 	\KwData{New packet, List of connected IP addresses: $ip\_list$}
	\KwResult{Configure the bandwidth for a candidate peer}
	\BlankLine
	\While{TRUE}{
	  	$packet \Leftarrow$ {\bf read\_new\_packet}()\;
	  	$ip \Leftarrow$ {\bf check\_header}($packet$)\;
		\eIf{$ip$ is new}{
   			$country\_code \Leftarrow$ {\bf resolve\_location}($ip$)\;
   			\eIf{$country\_code$ != ``JP"}{
   				$bw \Leftarrow$ C;
	   			{\bf call\_dummynet\_for\_limiting\_bandwith}($ip, bw$)\;	
   			} {
   				{\bf do\_nothing};
   			}
   			$ip\_list \Leftarrow$ {\bf add\_new\_ip\_to\_list}($ip$);
   		}{
   			{\bf do\_nothing};
  		}
 	}
 	\end{footnotesize}
 	\centering \caption{Fixed-length bandwidth limitation scheme: configure the bandwidth for a new peer}
\label{alg1}
\end{algorithm}

For the fixed-length bandwidth limitation scheme, the value of limited bandwidth is constant for all foreign peers. The implementation is therefore very simple as shown in algorithm \ref{alg1}.  For every new peer coming to the router, we simply check its country information and apply bandwidth limitation if the peer does not come from Japan.   

For the hierarchical bandwidth limitation scheme, the value of limited bandwidth depends on the numbers of peers in the same area as the querying peer. Since these numbers may be changed when a new peer comes, the limited bandwidth values of all connected peers should be recomputed again many times. This causes high CPU usage and affects other processes of the router. In addition, the bandwidth limitation strategy might not be effective in traffic localization if we change the configuration too often. Therefore, our solution is to compute the limited bandwidth for the new peer in real time and to recalculate the limited bandwidth for all the connected peers every one minute. This avoids the high load on the router's CPU, and ensures a regular updating of the bandwidth value for all connections. Algorithms \ref{alg2} and \ref{alg3} show pseudo codes of bandwidth configuration for a new peer and bandwidth reconfiguration for a list of connected peers, respectively.

\begin{algorithm}[t]
	\begin{footnotesize}
 	\KwData{New packet}
	\KwResult{Configure the bandwidth for a new peer}
	\BlankLine
	\While{TRUE}{
	  	$packet \Leftarrow$ {\bf read\_new\_packet}()\;
	  	$ip \Leftarrow$ {\bf check\_header}($packet$)\;
		\eIf{$ip$ is new}{
   			$(as, isp, country, lat, lon) \Leftarrow$ {\bf resolve\_location}($ip$)\;
   			$(n_1, n_2, n_3) \Leftarrow$ {\bf update\_no\_peers\_same\_area}($as, isp,$ \ $country$)\;
   			$logical\_distance \Leftarrow$ {\bf compute\_logical\_distance}($as, isp,$ \ $country, lat, lon, n_1, n_2, n_3$)\;
   			$bw \Leftarrow$ {\bf compute\_limited\_bandwidth}($logical\_distance$)\;
   			{\bf call\_dummynet\_for\_limiting\_bandwith}($ip, bw$)\;
   			$ip\_list \Leftarrow$ {\bf add\_new\_ip\_to\_list}($ip$);
   		}{
   			{\bf do\_nothing};
  		}
 	}
 	\end{footnotesize}
 	\centering \caption{Hierarchical bandwidth limitation scheme: configure the bandwidth for a new peer}
\label{alg2}
\end{algorithm}

\section{Experimental results}
\subsection{Experimental setup}
In this setup, the proposed router is placed as a subnet gateway router as shown in Fig.\ \ref{fig:network_environment}. We performed experiments using P2PTV applications because of their popularity. Two types of P2PTV applications are selected: SopCast version 3.5.0 for performing video live streaming and PPStream version 3.2.0.1067 for performing video-on-demand service. These applications did not consider peer locality, as reported in several previous studies \cite{Su2008,Horvath2009}. We set each application to run one-by-one on the measurement hosts. On SopCast we played a live Chinese channel, CCTV-2. On PPStream, an on-demand drama popular in Japan was selected for the experiment. The average bit rates of these two video streams were 800kbps and 705kbps, respectively. Since we also wanted to check the possibility that a measurement host downloading the video data from the very neighbor peer inside our laboratory, we always run each P2P application on two measurement hosts simultaneously, as host 1 and host 2. All the experiments were conducted in September 2013 in our laboratory. The location information of measurement hosts in detail is as follows: 
\begin{itemize}
\item{AS number: AS4713}
\item{ISP: NTT Communications Corp.}
\item{Country: Japan.}
\end{itemize}
We utilize {\tt Wireshark} \cite{Wireshark}, a well-known packet sniffer application, to generate statistical information of traffic on the measurement hosts. Since we skip the implementation of the traffic classification module, only P2P applications and Wireshark are permitted to run on the measurement hosts.

\begin{figure}[b]
\centering
\includegraphics[width=0.4\textwidth]{JCSCE2014_network_environment.eps}
\caption{The proposed router architecture.}
\label{fig:network_environment}
\end{figure}

The values of the parameters in the equations were chosen as follows: $C = 800$, $\varepsilon = 0.1$, $\theta_1 = \theta_2 = 1000$, $\theta_3 = 2000$, $\varepsilon_1 = 1$, and $B = 2000000$.

\begin{algorithm}[t]
	\begin{footnotesize}
 	\KwData{List of connected IP addresses: $ip\_list$}
	\KwResult{Reconfigure the bandwidth for all connected peers}
	\BlankLine
	{\bf call\_dummynet\_for\_flushing\_all\_old\_configurations}()\;
	$(n_1, n_2, n_3) \Leftarrow$ {\bf count\_no\_peers\_same\_area}($ip\_list$)\;	
	\For{$i = 1$ \KwTo ${\bf count}(ip\_list$)}{
		$(as, isp, country, lat, lon) \Leftarrow$ {\bf get\_location}($ip\_list[i]$)\;
		$logical\_distance \Leftarrow$ {\bf compute\_logical\_distance}($as, isp,$ \ $country, lat, lon, n_1, n_2, n_3$)\;
   		$bw \Leftarrow$ {\bf compute\_limited\_bandwidth}($logical\_distance$)\;
   		{\bf call\_dummynet\_for\_limiting\_bandwith}($ip, bw$);
	}		
	\end{footnotesize}
	\centering \caption{Hierarchical bandwidth limitation scheme: reconfigure the bandwidth for all connected peers}
\label{alg3}
\end{algorithm}

\begin{figure*}[ht!]
	\centering
        \subfloat[Keep original behavior of SofCast, host 1.]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_sopcast_throughput_bw01.eps}
        }%
        \subfloat[Apply fixed-length bandwidth limitation scheme, host 2.]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_sopcast_throughput_bw800.eps}
        }%
    \caption{%
        Temporal changes of throughput when simultaneously keeping original behavior of SopCast on the measurement host 1 and applying the fixed-length bandwidth limitation scheme on the measurement host 2.
     }%
   \label{fig:sopcast_throughput_fixedlength_method} 
\end{figure*}

\begin{figure*}[ht!]
	\centering
        \subfloat[Keep original behavior of SofCast, host 1.]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_sopcast_throughput_bw02.eps}
        }%
        \subfloat[Apply hierarchical bandwidth limitation scheme, host 2.]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_sopcast_throughput_bw_hierarchy.eps}
        }%
    \caption{%
        Temporal changes of throughput when simultaneously keeping original behavior of SopCast on the measurement host 1 and applying the hierarchical bandwidth limitation scheme on the measurement host 2.
     }%
   \label{fig:sopcast_throughput_proposed_method} 
\end{figure*}

\subsection{Criteria of Evaluation}
To evaluate the effectiveness of the proposed method, we compared the results of three different schemes: (1) random and/or RTT-based peer-selection scheme, i.e., the original behavior of P2PTV applications; (2) fixed-length bandwidth limitation scheme, in which the bandwidth of all the connections to foreign peers were limited at 800kbps maximum. We chose 800kbps as a limited value because 800kbps is approximate equal to the average bit rates of the two video streams of SopCast and PPStream; (3) hierarchical bandwidth limitation scheme.
   
We compared the results of three schemes from two viewpoints: the traffic locality and the QoS. From the former viewpoint, we measured the volume of downloaded data and the number of neighbor peers, and reported their ratios by regions as evaluation indexes. For each scheme, we ran each P2P application three times, with 300 seconds each time. The means of evaluation indexes were calculated as final results. 

From the latter viewpoint, QoS, we evaluated the quality performance of SopCast and PPStream. Since SopCast is a live streaming application, we measured the average waiting time of users. The waiting time is the time that users have to wait for the application to buffer enough data for starting playing. Therefore, the waiting time reflects the down load speed, and thus can be used as a metric for evaluating the application performance. On PPStream, because we ran an on-demand video, we measured the size of cached file buffered by PPStream within 300 seconds of the measurement. 

\begin{figure*}[ht!]
	\centering
        \subfloat[Downloaded data distribution]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_sopcast_data_ratio.eps}
        }%
        \subfloat[Neighbor peer distribution]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_sopcast_peer_ratio.eps}
        }
    \caption{%
        Downloaded data distributions and neighbor peer distributions for SopCast in three modes of bandwidth limitation.
     }%
   \label{fig:sopcast_data_peer_ratio} 
\end{figure*}

\subsection{Results with SopCast}
First, we present the results obtained with SopCast. Figure \ref{fig:sopcast_throughput_fixedlength_method} shows an example of temporal changes of throughput when keeping original behavior of SopCast on the measurement host 1 and applying the fixed-length bandwidth limitation scheme on the measurement host 2. In case of no limitation, traffic measured on host 1 comes from many countries including China, Japan, the United State and the others. However, host 1 did not recognize and download video data from the very neighbor peer, host 2. In particular, the traffic coming from host 2 is zero as shown in Fig. \ref{fig:sopcast_throughput_fixedlength_method} (a). In case of applying fixed-length bandwidth limitation, most traffic measured on host 2 comes from Japan because SopCast tends to remove connection paths with foreign peers due to a lower bandwidth. However, the traffic coming from the very neighbor peer, host 1, is very small. This is because the scheme does not distinguish the very neighbor peer from the other Japanese peers, SopCast can download video data pieces from the very neighbor peer at one time, and from other Japanese peers at other times when the new peers are better.

Figure \ref{fig:sopcast_throughput_proposed_method} shows an example of temporal changes of throughput when keeping original behavior of SopCast on the measurement host 1 and applying the hierarchical bandwidth limitation scheme on the measurement host 2. With the hierarchical scheme, almost all the traffic measured on host 2 is downloaded from the very neighbor peer, host 1, with IP address 192.168.12.32 as shown in Fig. \ref{fig:sopcast_throughput_proposed_method} (b). In contrast, at the same time host 1 could not download any video data from its very neighbor peer, host 2. This is because our hierarchical scheme has degraded network performance of inter-AS connections by limiting their bandwidth. Therefore, SopCast tends to preferably download video data pieces from the neighbor peer in the same AS that usually has better performance than other peers, e.g., shorter RTT. The feature of our hierarchical bandwidth limitation scheme that forces a P2P streaming application to download the data from a peer in the same LAN is very significant. To the best of our knowledge, no other research shows the same result to ours.



\begin{footnotesize}
\begin{table}[t]
\setbox0\hbox{\verb/\documentclass/}%
  \centering
  \caption{Average waiting time of SopCast.}
%	\resizebox{8cm}{!} {
        \begin{tabular}{|l|r|}
    	    \hline
    	    \textbf{Bandwidth limitation modes} & \textbf{Average waiting time [s]} \\ \hline
    	    No limit & 13.45 \\ \hline
    	    Fixed-length (800kbps) & 42.50 \\ \hline
    	    Hierarchy & 14.00 \\ \hline
        \end{tabular}%
%    }
  \label{tab:sopcast-qos}%
\end{table}%
\end{footnotesize}

Figure \ref{fig:sopcast_data_peer_ratio} (a) presents the average downloaded data distributions by three schemes. The vertical axis represents the region-by-region ratios for the downloaded traffic that the measurement host received from other peers. We listed the ratios by ASes/ISPs for the traffic inside Japan, and by countries for the overseas traffic. The information of AS and ISP was grouped together in the results because we had not found any traffic coming from different AS in the same ISP in the experiments. We marked that the traffic coming from outside of AS4713 NTT Communications Corp. as cross-AS/ISP traffic. The cross traffic accounts for 95\% of the total traffic in case of no limit, i.e., original behavior of SopCast. This is a very high percent of inter-domain traffic. In case of fixed-length bandwidth limitation scheme, almost all traffic comes from Japan. This indicates that SopCast tends to preferably download data pieces from Japanese peers that have better performance than foreign peers due to bandwidth limitation applied to overseas traffic. However, the cross-AS/ISP traffic is still very high, which accounts for 94\% of the total traffic. On the other hand, with the hierarchical bandwidth limitation scheme, such the cross traffic accounts for only 13\% of the total traffic. This statistic shows that our hierarchical scheme significantly reduces the cross-AS/ISP traffic.

Figure \ref{fig:sopcast_data_peer_ratio} (b) illustrates the neighbor peer distributions by three schemes, where the vertical axis represents the region-by-region ratios of the number of peers that the measurement host communicated with. Figure \ref{fig:sopcast_data_peer_ratio} (b) indicate that the neighbor peer distributions do not vary much and almost independent of the bandwidth limitation. This can be explained as follows: SopCast first contacts with some peer list servers to obtain a list of available online peers, and then forms an overlay network for exchanging video data pieces with a subset of those peers. Our bandwidth limitation schemes, however, cannot intervene at the step of obtaining the peer list. The neighbor peer distributions are therefore pretty stable. Nevertheless, the application preferably selects closer peers to download data pieces even when very few candidates exist. Our proposal thus successfully realizes traffic localization on SopCast.

Table \ref{tab:sopcast-qos} shows the average waiting time for SopCast by three schemes. It is easy to see that the fixed-length bandwidth limitation scheme degrades the performance of SopCast. In comparison with the original behavior of SopCast, the waiting time is much longer in case of 800kbps bandwidth limitation. This is because the fixed-length bandwidth limitation scheme always limits the bandwidth of overseas traffic even when very few Japanese peers exist for localizing. In the worst case, no Japanese peer for contact, the waiting time of SopCast will be very long due to bandwidth limitation applied to overseas traffic. In contrast, the waiting time of the hierarchical bandwidth limitation scheme is almost the same as that of the original behavior. These results show the effectiveness of the hierarchical feature. In case of no Japanese peer for contact, no bandwidth limitation is applied as described in previous section. Therefore, we conclude that the hierarchical bandwidth limitation scheme also maintains the quality performance of SopCast.  

\begin{figure*}[ht!]
	\centering
        \subfloat[Keep original behavior of PPStream, host 1]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_pps_throughput_bw01.eps}
        }%
        \subfloat[Apply fixed-length bandwidth limitation scheme, host 2]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_pps_throughput_bw800.eps}
        }%
    \caption{%
        Temporal changes of throughput when simultaneously keeping original behavior of PPStream on the measurement host 1 and applying the fixed-length bandwidth limitation scheme on the measurement host 2.
     }%
   \label{fig:pps_throughput_fixedlength_method} 
\end{figure*}

\begin{figure*}[ht!]
	\centering
        \subfloat[Keep original behavior of PPStream, host 1]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_pps_throughput_bw02.eps}
        }%
        \subfloat[Apply hierarchical bandwidth limitation scheme, host 2]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_pps_throughput_bw_hierarchy.eps}
        }%
    \caption{%
        Temporal changes of throughput when simultaneously keeping original behavior of PPStream on the measurement host 1 and applying the hierarchical bandwidth limitation scheme on the measurement host 2.
     }%
   \label{fig:pps_throughput_proposed_method} 
\end{figure*}

\begin{figure*}[ht!]
	\centering
        \subfloat[Downloaded data distribution]{%
            \includegraphics[width=0.4\textwidth]{JCSCE2014_pps_data_ratio.eps}
        }%
        \subfloat[Neighbor peer distribution]{%
           \includegraphics[width=0.4\textwidth]{JCSCE2014_pps_peer_ratio.eps}
        }
    \caption{%
        Downloaded data distributions and neighbor peer distributions for PPStream in three modes of bandwidth limitation.
     }%
   \label{fig:pps_data_peer_ratio} 
\end{figure*}

\begin{footnotesize}
\begin{table}[t]
\setbox0\hbox{\verb/\documentclass/}%
  \centering
  \caption{Average size of cached file buffered by PPStream within 300 seconds.}
%	\resizebox{8cm}{!} {
        \begin{tabular}{|l|r|}
    	    \hline
    	    \textbf{Bandwidth limitation modes} & \textbf{Size of cached file [MB]} \\ \hline
    	    No limit & 195 \\ \hline
    	    Fixed-length (800kbps) & 43 \\ \hline
    	    Hierarchy & 193 \\ \hline
        \end{tabular}%
%    }
  \label{tab:pps-qos}%
\end{table}%
\end{footnotesize}

\subsection{Results with PPStream}
Secondly, we present the results obtained with PPStream. The experiments are performed in a similar manner to SopCast case. Figure \ref{fig:pps_throughput_fixedlength_method} presents an example of throughput changing when simultaneously keeping original behavior of PPStream on the measurement host 1 and applying fixed-length bandwidth limitation scheme on the measurement host 2. The results resemble the SopCast case. In particular, when applying the fixed-length bandwidth limitation, almost all the traffic measured on host 2 comes from Japan. This feature proves the success of bandwidth limitation scheme in P2P traffic localization. However, both hosts could not recognize the very neighbor peer to download video data pieces. In contrast, Fig.\ \ref{fig:pps_throughput_proposed_method} indicates that in case of applying the hierarchical bandwidth limitation on host 2 and keeping original behavior of PPStream on host 1, almost all the traffic comes from the very neighbor peer, host 1. Simultaneously, host 1 did not download any video data from its very neighbor peer, host 2.

Figure \ref{fig:pps_data_peer_ratio} shows the downloaded data distributions and the neighbor peer distributions by three schemes. The results indicate that even though the neighbor peer distributions are fairly steady, the amount of data received from Japan increases dramatically in case of applying bandwidth limitation method. Furthermore, the amount of the cross-AS/IP traffic decreases significantly when applying the hierarchical bandwidth limitation scheme. As shown in Fig. \ref{fig:pps_data_peer_ratio} (a), the cross-AS/ISP traffic accounts for 95\%, 99\%, and 6\% of the total traffic in case of no limit, fixed-length bandwidth limitation, and hierarchical bandwidth limitation scheme, respectively.

Table \ref{tab:pps-qos} presents the average size of cached file for PPStream within five minutes by three schemes. Similar to SopCast case, the fixed-length bandwidth limitation scheme also degrades the performance of PPStream. In particular, the average cached file size in case of fixed-length scheme is 43MB, much smaller than that of original behavior of PPStream, 195MB. On the other hand, the cached file size of the hierarchical bandwidth limitation scheme is almost the same as that of no limitation case. Based on the very similarity in results of PPStream and Sop-Cast, we believe that the communication protocols of these two applications are probably very similar. 

\section{Conclusion}
In summary, this paper provides the following meaningful contributions to the field of P2P traffic localization: (1) we proposed two different schemes based on bandwidth limitation, to solve the problem on network layer; (2) with the hierarchical scheme, the traffic can be localized hierarchically with multiple levels including AS level, ISP level, and country level; (3) our proposals requires neither modification of existing application software, nor dedicated server, nor collaboration between ISPs and P2P users. The experiment measurements indicate that the fixed-length bandwidth limitation successfully realized traffic localization by the suppression of the connection paths with the foreign peers. Moreover, our hierarchical bandwidth limitation scheme significantly reduces the cross AS/ISP traffic. In particular, the cross-AS/ISP traffic decreases by 82\% for SopCast and 91\% for PPStream, in comparison to original behavior of these two applications. 

Several future challenges remain. First, we only measured the waiting time as a QoS evaluation metric. In the future, we will investigate the QoS with many other factors when applying the bandwidth limitation. Second, the effectiveness of our proposed router in a real network might be influenced much by the accuracy of the traffic classification module. Therefore, we are also planning to consider deeply the traffic classification module to complete our router-aided approach. 





% if have a single appendix:
%\appendix[Proof of the Zonklar Equations]
% or
%\appendix  % for no appendix heading
% do not use \section anymore after \appendix, only \section*
% is possibly needed

% use appendices with more than one appendix
% then use \section to start each appendix
% you must declare a \section before using any
% \subsection or using \label (\appendices by itself
% starts a section numbered zero.)
%


%\appendices
%\section{Proof of the First Zonklar Equation}
%Appendix one text goes here.

% you can choose not to have a title for an appendix
% if you want by leaving the argument blank
%\section{}
%Appendix two text goes here.


% use section* for acknowledgement
\section*{Acknowledgment}
This study was partly supported by a Grant-in-Aid for Young Scientists (B) No. 23760344 from the Japan Society for the Promotion of Science (JSPS).



% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
\ifCLASSOPTIONcaptionsoff
  \newpage
\fi

%\begin{thebibliography}{1}
%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
%\end{thebibliography}

\bibliographystyle{IEEEtran}% bib style
\bibliography{HiephvBibAll}% your bib database

% biography section
% 
% If you have an EPS/PDF photo (graphicx package needed) extra braces are
% needed around the contents of the optional argument to biography to prevent
% the LaTeX parser from getting confused when it sees the complicated
% \includegraphics command within an optional argument. (You could create
% your own custom macro containing the \includegraphics command to make things
% simpler here.)
%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{mshell}}]{Michael Shell}
% or if you just want to reserve a space for a photo:

\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{hiephv.eps}}]{Hiep Hoang-Van}
received the B.E.\ and M.S.\ degrees in computer engineering and communication from Hanoi University of Science and Technology in 2007 and 2011, respectively. Currently, he is doing his research as a doctoral student at Graduate School of Engineering and Science, Shibaura Institute of Technology, Japan. His research interests include multimedia communication technologies, P2P systems, P2P traffic engineering. He is a student member of IEICE.
\end{IEEEbiography}

% if you will not have a photo at all:
\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{miyoshi.eps}}]{Takumi Miyoshi}
received the B.Eng., M.Eng., and Ph.D.\ degrees in electronic engineering from the University of Tokyo, Japan, in 1994, 1996, and 1999, respectively. He was a visiting associate from 1994 to 1996 and an Internet technical staff from 1996 to 1997 at the Institute for Monetary and Economic Studies, Bank of Japan. He was also a research associate at Global Information and Telecommunication Institute, Waseda University, from 1999 to 2001, and a research fellow at Telecommunications Advancement Organization of Japan from 1998 to 2003. He is presently a professor at Department of Electronic Information Systems, College of Systems Engineering and Science, Shibaura Institute of Technology, Saitama, Japan. He was a visiting scholar at Laboratoire d'Informatique de Paris 6 (LIP6), UPMC Sorbonne Universit\'{e}s (Paris 06), Paris, France, from 2010 to 2011. His research interests include multimedia communication technologies, mobile ad hoc and sensor networks, and online learning systems. He received the IEICE Young Investigators Award in 2004, the IEICE Network System Research Award in 2010, the IEICE Information Network Research Award in 2001, 2004, and 2006, the IEICE Communications Society Distinguished Contributions Award in 2006, 2007, 2009, and 2010, and Ericsson Young Scientist Award in 2002. He is also a member of IEEE.
\end{IEEEbiography}
% insert where needed to balance the two columns on the last page with
% biographies
%\newpage

\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{olivier.eps}}]{Olivier Fourmaux}
is an associate professor at UPMC Sorbonne Universit\'{e}s (Paris 06), France, since 2003. Before, he was an assistant professor at Institut Galil\'{e}e, Universit\'{e} Paris 13, France. He received his Ph.D.\ degree in computer networking in 1998 and his M.Sc.\ degree in computer systems in 1995, both from UPMC. His research interests are content delivery networks, P2P networks, active networks and multimedia in high-speed networks. He is a member of the Network and Performance group of the LIP6 Laboratory (CNRS-UPMC). He is also a member of IEEE.
\end{IEEEbiography}
% You can push biographies down or up by placing
% a \vfill before or after them. The appropriate
% use of \vfill depends on what kind of text is
% on the last page and whether or not the columns
% are being equalized.

%\vfill

% Can be used to pull up biographies so that the bottom of the last one
% is flush with the other column.
%\enlargethispage{-5in}



% that's all folks
\end{document}


