Understanding of Network Operator-friendly P2PTraffic Control Techniques in Intra Domain

HyunYong LeeNational Institute of Information andCommunications Technology (NICT)

Email: ifjesus7@gmail.com

Akihiro NakaoThe University of Tokyo

Email: nakao@iii.u-tokyo.ac.jp

JongWon KimGwangju Institute of Science

and Technology (GIST)Email: jongwon@nm.gist.ac.kr

Abstract—Existing network operator-friendly P2P traffic con-trol techniques like P4P argue that network operators canreduce inter-domain traffic while peer-to-peer (P2P) applicationscan improve their performance through the traffic localization.However, the existing work has not addressed how the trafficlocalization affects an intra-domain traffic control in detail. Infact, not considering the impact on intra-domain traffic maylead to a suboptimal performance, since intra and inter-domaintraffic control usually have different goals and requirements.This paper elaborates performance investigation of intra-domaintraffic control by the existing techniques. Through simulations,we reveal the performance-based technique (utilizing a dynamicnetworking status) shows attractive features compared to thedistance-based technique (utilizing a locality-aware information)while the performance-based technique has potential problemthat may block a fine-grained traffic control. Based on theobservations, we provide one guideline to solve an identifiedlimitation of the existing technique.

I. INTRODUCTION

The network operator-friendly P2P traffic control techniquehas been proposed [3]-[8] to gain control over inter-domainpeer-to-peer (P2P) traffic that has recently increased signif-icantly to press inter-domain links [1]. In this technique,peers are supposed to select their communication partnersby following a guidance issued by the network operators orthrough publicly available information so that some of inter-domain traffic may be redirected within a local domain withoutsacrificing P2P system performance. The existing work [3]-[8]has shown that the network operators can successfully reduceinter-domain traffic, while the peers can actually achieve betterperformance with the technique than without it.

However, the most existing work does not show how thelocalized traffic impacts intra-domain traffic control in detailwhile focusing on the localization of inter-domain traffic. Ifthe locality is enforced without enough consideration on intra-domain traffic, (e.g., each peer simply downloads contentfrom the closest peer), some peers may encounter highlycongested intra-domain links. The problem may get worseas volume of the localized traffic increases as a result ofthe technique turning inter-domain traffic into intra-domainone. Even though some work [3] shows how their approacheswork in intra-domain, detailed performance study of variousapplication ways of them is missing.

Basically, the existing techniques can be categorized intotwo groups according to the guidance type as distance-based

and performance-based techniques [12]1. For example, thenetwork operator-supported approach [3], [5], [6] can beimplemented as both since the network operator has flexibilityin a selection of network information for the guidance. Onthe other hand, the implementation of the approach utilizingpublicly available information [7], [8] is restricted by the infor-mation. Therefore, we need to understand how the above twocategorized techniques affect the intra-domain traffic controlfor better network operator-friendly P2P traffic control.

To this end, this paper tries to understand performanceimpact of the existing techniques to intra-domain traffic controlin addition to inter-domain traffic control that has alreadygained much attention. For this, we conduct a series ofsimulations on one intra-domain topology that is built basedon our observation of real BitTorrent swarms with followingtechniques: BitTorrent with the distance-based technique (DG)and BitTorrent with the performance-based technique (PG).We also include vanilla BitTorrent (BT) as a base case whereno guidance is available. Then, we simulate above threetechniques with various ratios of peers that follow the guidanceto total peers to examine the techniques from various aspects.

Our contributions in this paper are two-fold. First, throughthe simulations, we have obtained the following findings: (1)PG shows lowest traffic overhead although it shows slightlylonger content download path than DG. (2) PG distributes thetraffic over intra-domain links by avoiding highly utilized link.(3) But, PG shows a traffic oscillation on intra-domain linksthat may block a fine-grained traffic control. Second, based onour findings, we propose one guideline to solve an identifiedproblem of PG which causes the traffic oscillation problem.

The rest of this paper is organized as follows. SectionII describes our evaluation methodology, while Section IIIshows our observations. Section IV discusses a solution forthe identified limitation of existing technique. Lastly, SectionV concludes this paper.

II. EVALUATION METHODOLOGY

From now on, for the sake of simplicity, we use followingterms. A guided peer is the peer that follows the guidance

1We categorize the existing techniques like this way instead of groupingthem based on their architectures since we believe that the guidance itselfmay have greater impact on performance than the architectures generating theguidance. Note that same guidance can be generated by different techniques.

97978-1-61284-663-7/11/$26.00 ©2011 IEEE ICOIN 2011

Fig. 1. Simulation topology.

and a non-guided peer is the peer that does not follow theguidance. Guided traffic is the P2P traffic that is generated byrequests of the guided peers. The rest is non-guided traffic.We conduct our evaluation using ns-2 simulator [15] withfollowing settings.

A. Simulation Setup

To build real intra-domain topology, we have first collectedthe IP addresses of the real peers by joining BitTorrent swarmswith more than 350 torrents downloaded from IsoHunt [16],which is a famous torrent site. From the collected IP addressesand through Cymru AS mapping service [17] that maps an IPaddress to the AS that it belongs to we have identified the ASwith largest number of peers among ASes that Rocketfuel [19]has revealed their intra-domain topologies. The selected intra-domain contains 14 network scopes (NSes), where an NS isa cluster sharing the same IP network prefix, and 25 inter-NSlinks (i.e., intra-domain links) having different latency (fromRocketfuel data). Each NS contains different number of peersbased on our measurement (from 5 to 75) so in total there are330 peers. For various experimental settings, we use differentratios of guided peers to the total peers since we can not expectthat every peer follows the guidance. The non-guided peersgenerate variable non-guided traffic in addition to the staticbackground traffic that accounts for up to 20% of 50Mbpslink capacity.

We use BitTorrent [2] as P2P application and 50MB(256KB) sized content (chunk). We set 1500Kbps and500Kbps as download and upload capacity of peers, respec-tively. Peers join the swarm randomly from 0 to 10 secondsafter simulation starts.

We simulate three approaches for peer selection in intra-domain. BT is used as the basis of performance comparison.

For DG, we utilize NS hops to generate a guidance since it issimple and applicable in intra-domain. To implement DG, wedesign BitTorrent tracker so that it returns neighboring peersclose to a newly joining peer in terms of NS hops insteadof controlling peer communications based on the networkdistance during BitTorrent swarming. By doing this, we try toprovide sufficient connectivity required for good performancein content sharing while still allowing peers to communicate

with peers close to themselves.For PG, we use an link utilization since the link utilization

is an easy way to understand networking status. PG utilizesthe link utilization in addition to the closeness of DG since thebasic concept of the network operator-friendly traffic controlis to download a content from nearby peers. We calculatethe link utilization every 5 seconds and generate the guidancefrom NSm to NSn which is defined as 1 - max(link utilizationof the intra-domain links from NSm to NSn). In PG, theguided peers try to generate the guided traffic from NSesproportional to the corresponding guidance. In order to dothis, we use BitTorrent’s ‘INTERESTED’ message since themessage triggers chunk transfer if the request is unchoked2.We implement one guidance server that maintains the rate of‘INTERESTED’ messages that may be transmitted between anarbitrary pair of NSes. Each peer checks whether it can sendan ‘INTERESTED’ message to a certain NS by accessing theguidance server.

B. Performance Metrics

One main objective of the intra-domain traffic control is todistribute the traffic evenly over intra-domain links so as toprovision more bandwidth [3]. Thus, we aim to study rela-tionship between the traffic control technique and the guidedtraffic generation. First, we check how each technique affectstraffic overhead on intra-domain links using the following twometrics: inNS/outNS (where inNS is the amount of chunksreceived within the same NS and outNS is the amount ofthose downloaded from the other NSes) and avg NS hops (theaverage number of intra-domain links used for downloadingthe chunks from the other NSes). Then, we examine howthe traffic is distributed over intra-domain links by usingmaximum link utilization (MLU) and the variation of linkutilization (VAR). Then, to check the degree of link congestionby the guided traffic, we define congestion contribution ratio(CCR) as (Guided traffic volume / Link capacity) * Linkutilization. Intuitively, an intra-domain link is more likely to becongested by the guided traffic as an link utilization is higherand a guided traffic volume is larger. Finally, we define traffic

oscillation factor (TOF) as (T

lki−1∑T

lki−1

− Tlki∑T

lki

)2 (where T lki

is a traffic volume of link lk at ith interval and lk is a set ofintra-domain links that are connected to given certain NS) tocheck a degree of traffic oscillation on intra-domain links.

To check the performance of P2P content sharing, we usedownload completion time since all peers try to finish theirdownload as soon as possible.

III. EVALUATION

We now report the representative results that demonstrateour main observations. We run simulation multiple timesand show the average across results. From now on, unlessotherwise stated, the results indicate the simulation with 100%ratio of guided peer to total peers.

2We say that peer A is unchoked by peer B when B is willing to send datato A who issued a data request to B.

98

TABLE ITRAFFIC OVERHEAD ON INTRA-DOMAIN LINKS

Metric BT DG PGInNS (in Mbits) 8377 31373 35658

OutNS (in Mbits) 59001 36005 31720InNS/OutNS 0.141 0.871 1.124Avg NS hops 1.7 1.2 1.3

Fig. 2. Avg NS hops with varying ratio of the guided peers.

A. Traffic Overhead

Firstly, we examine how much guided traffic is generated onintra-domain links (Table I). The absence of guidance in BTresults in highest traffic overhead (i.e., lowest InNS/OutNS)and longest path length by allowing the peers to downloadchunks from farther peers that belong to other NSes. On theother hand, DG and PG show less traffic overhead and shorterpath length than BT by enabling the peers to download chunksfrom close peers including same NS. In addition, PG showsfurther improvement compared to DG in terms of the trafficoverhead. Actually, PG is more likely to limit chunk downloadfrom other NSes since PG reflects the underlying networkingstatus in addition to the closeness (of DG) for the guidance.However, the adoption of the underlying networking status inPG results in slightly increased avg NS hops compared to DG.Even though PG reduces OutNS, when the communicationswith peers of other NSes are allowed, the peers in PG aremore likely to communicate with farther peers. For example,if a peer has candidate peers who belong to two NSes that aredifferent in NS hops and link utilization (e.g., NS hops andlink utilization of intra-domain link to NS A and NS B are 1,90% and 2, 80%, respectively), the peer is likely to access toNS A in DG whereas the peer is likely to access to NS B inPG.

Varying ratio of guided peers. In this simulation, theratio of guided peers to total peers varies from 100% to10%. The guided peers show better performance than the non-guided peers as DG and PG show better performance thanBT. Note that the non-guided peers of DG and PG can beregarded as the peers of BT. As shown in Fig. 2, PG showshigher InNS/OutNS than DG. However, from 50% ratio of theguided peers, PG begins to lose its performance improvementmerit compared to DG even though PG (and DG) shows stillnoticeable performance improvement compared to BT.

(a) MLU (b) VAR

Fig. 3. Traffic distribution over intra-domain links (100% ratio of guidedpeers).

(a) MLU (b) VAR

Fig. 4. Traffic distribution over intra-domain links (10% ratio of guidedpeers).

In summary, the closeness that is common in DG andPG is enough to reduce the traffic overhead. PG (adoptingthe underlying networking status) reduces the traffic overheadfurther than DG (simply enforcing the closeness) even thoughPG shows slightly increased avg NS hops than DG.

B. Traffic Distribution

Fig. 3 shows how the traffic is distributed over intra-domainlinks. BT shows highest imbalance of traffic overhead overintra-domain links. This is due to that BT has no guidanceexcept its peering policy and thus much traffic is unevenlydistributed over intra-domain links. On the other hand, DGand PG reduce MLU and VAR compared to BT by selectingclose peers so that intra-domain links have less amount ofguided traffic than BT. However, PG does not show furtherimprovement compared to DG like the traffic overhead case.We conjecture that the amount of guided traffic is not enoughto show noticeable improvement in terms of the traffic distribu-tion. Note that DG and PG already reduce the traffic overheadby around 50% compared to BT (see Table I).

Varying ratio of guided peers. In this simulation, we findthat the performance of DG decreases faster than that of PG.Actually, PG begins to show further improvement comparedto DG from around 50% ratio of guided peers and PG showsa noticeable improvement in 10% guided peers compared toDG as shown in Fig. 4.

One interesting observation here is that PG does not showa noticeable performance improvement compared to DG incase of 100% ratio of guided peers where much guidedtraffic is generated while PG shows a noticeable improvement

99

Fig. 5. A degree of link congestion by the guided traffic (100% ratio ofguided peers).

(a) DG (b) PG

Fig. 6. A degree of link congestion by the guided traffic (varying ratio ofguided peers).

compared to DG in lower ratio of guided peers (i.e., from50%) where less guided traffic is generated. Regarding this,we find that two cases have different type of non-guided traffic.For example, the non-guided traffic of 100% ratio of guidedpeers is static (i.e., only static background traffic) and the non-guided traffic of lower ratio of guided peers is dynamic (i.e.,static background traffic and variable non-guided traffic by thenon-guided peers). In other words, DG (and also PG) showsstable performance improvement with static non-guided trafficbut DG loses its performance improvement merit in terms ofthe traffic distribution with varying non-guided traffic sinceDG does not reflect underlying networking status. On theother hand, PG shows persistent performance improvementmerit regardless of given background traffic by reflecting thedynamic networking status. This result shows that PG showssomewhat persistent performance improvement compared toDG in terms of the traffic distribution.

In summary, the reduced traffic overhead by the guidanceof DG and PG (enabling peers to select close peers) leads tobetter traffic distribution than BT. DG loses its performanceimprovement merit with variable non-guided traffic while PGshows persistent performance improvement merit regardless ofgiven non-guided traffic by reflecting the underlying network-ing status.

C. Degree of Link Congestion

Now, we show how the generated guided traffic affectslink congestion and this result supports the aforementionedobservations. As shown in Fig. 5, PG shows lower CCR thanDG, which means that PG guides the guided peers to avoidhighly utilized links by reflecting the underlying networking

(a) DG

(b) PG

Fig. 7. A degree of guided traffic oscillation.

status. On the other hand, DG shows higher CCR by allowingthe peers to intensively communicate with close peers and asa result large amount of guided traffic is generated on intra-domain links connecting to neighboring NSes.

Varying ratio of guided peers. Basically, CCR decreasesas the ratio of guided peers decreases since the ratio of guidedtraffic to total traffic decreases. As shown in Fig. 6, PG showslower CCR than DG through the adoption of the underlyingnetworking status. However, DG and PG show similar CCRwith low (i.e., 10%) ratio of guided peers since the amountof guided traffic volume is not enough to show noticeableperformance difference between them.

In summary, from above results, we may conclude thata decisive factor for effective traffic distribution over intra-domain links is not the closeness but the adoption of theunderlying networking status.

D. Guided Traffic Oscillation

To achieve stable traffic control, the guided traffic generationneeds to be stable. Thus, we examine a degree of guided trafficoscillation through TOF. To show TOF, we select one NSshowing representative results while most NSes show similarresults. We show the results from 150 seconds to 500 seconds(when the swarming is active) to show TOF clearly. As shownin Fig. 7, PG shows higher TOF compared to DG since PGgenerates the guidance by reflecting a dynamically changingnetworking status. For clear understanding of this issue, letassume two links lk1 and lk2, where T lk1

i−1 > T lk2i−1, of (i-

1)th interval. Then the guidance is generated so as to preferlk2 for ith interval. After ith interval, if T lk2

i > T lk1i by

much guided traffic on lk2, the guidance will be generated

100

TABLE IIDOWNLOAD COMPLETION TIME

BT DG PGTime (sec) 632 630.6 629.1

to give preference to lk1 for (i+1)th interval and this maylead to much guided traffic on lk1 during (i+1)th interval,which means an oscillation of traffic volume between two linksand unstable traffic control. Intuitively, the traffic oscillationmay be unavoidable to adapt given non-guided traffic if thenon-guided traffic is dynamic. However, PG shows the trafficoscillation even with 100% ratio of guided peers where onlythe static background traffic exists. We believe that the trafficoscillation problem happens when new guidance is generatedbased on the networking status including the guided traffic thatis generated by old guidance. Regarding this, we will discussmore in next Section.

In summary, PG has potential weakness for unstable trafficcontrol due to the guided traffic oscillation, even though PGis better than DG in terms of the traffic overhead and thetraffic distribution. Thus, there should be an appropriate wayto mitigate the traffic oscillation problem while preserving theattractive features.

E. Download Completion Time

One interesting observation is that three approaches donot show noticeable performance difference in the downloadcompletion time as shown in Table II. The guided peers and thenon-guided peers also do not show performance difference inthe download completion time. Intuitively, selecting close peer(i.e., DG and PG) should improve the performance comparedto the one selecting peers randomly (i.e., BT). However, wefind that the intra-domain network is not enough to shownoticeable performance improvement through the selectionof close peers3. In other words, the latency of intra-domainnetwork is not so large. From this result, we may conjecturethat a conclusive factor for the performance improvement interms of the download completion time is not the selectionof close peers in intra-domain network but the traffic local-ization turning the inter-domain traffic into intra-domain one.Actually, as shown in existing work [3], [5], [7], the trafficlocalization significantly reduces the download completiontime by reducing RTT latency for content download [7].

In summary, if the latency of intra-domain links is not solarge, the network operator-friendly traffic control techniquesselecting close peers in the intra-domain network do notshow noticeable performance improvement in the downloadcompletion time without the traffic localization inside theintra-domain network.

IV. DISCUSSION

Based on our observations, we now discuss one guideline tosolve the identified problem of PG, i.e., the traffic oscillation.

3It may depend on the used intra-domain network for the simulation anddifferent results may be acquired from different intra-domain networks.

Fig. 8. Solution for the guidance dependency problem.

The adoption of underlying networking status in PG hasattractive features in intra-domain traffic control. However,we reveal that PG has the traffic oscillation issue that can becaused by one problem (can be called guidance dependencyproblem) where new guidance reflects networking status in-cluding the guided traffic by old guidance. In other words, theguidance (that controls generation of the guided traffic and asa result affects networking status) and the networking status(that affects the guidance generation) depend on each other.The guidance dependency problem may prevent the networkoperator from understanding networking status accurately andgenerating finer guidance that can lead to finer-grained trafficcontrol and thus further performance improvement.

One possible approach to solve the guidance dependencyproblem is to distinguish the guided and non-guided traffic sothat new guidance does not reflect the guided traffic. For this,we need to measure the guided traffic as well as the total trafficvolume, which may lead to flow-level traffic measurementand analysis overhead. Moreover, measuring the P2P traffichas various obstacles including dynamic port change and dataencryption and this may result in measurement error [14].

As one guideline to solve the guidance dependency problemwhile avoiding the measurement overhead and error, we pro-pose one method to utilize the peer reports as shown in Fig. 8.We believe that this method can be applied to the guidanceusing traffic volume-related information like link utilization.At every interval for the guidance generation, the guidedpeers report information about their guided traffic (includingcommunication partner who sent traffic to themselves andcorresponding traffic volume) during previous interval to thenetwork operator. We believe that this approach does notcause noticeable measurement overhead to the peers sincemaking a simple log about the received guided traffic is enoughfor the traffic information. Then, the network operator cancalculate the guided traffic volume of intra-domain links sinceit knows a routing path and the guided traffic is only generatedby requests of the guided peers. The network operator cancalculate the non-guided traffic volume by subtracting thecalculated guided traffic volume from the total traffic volumethat can be acquired through SNMP query. This approachallows the network operator to distinguish the guided and non-guided traffic with low measurement overhead and to generatebetter guidance by avoiding the guidance dependency problem.

As one possible application way of the above approach, thenetwork operator may be able to estimate an allowable guided

101

traffic volume as follows:

glki−1 =

|A|∑n=1

|A|∑m=1,m �=n

qnmi−1 ∗ rlk,nmi−1 , (1)

nglki−1 = slki−1 − glki−1, (2)

glki = clk ∗D − nglki , (3)

where A is a set of NSes, qnmi−1 is the guided traffic volumefrom NSn to NSm during (i-1)th interval, rlk,nmi−1 is 1 (if trafficfrom NSn to NSm passes lk) or 0 (otherwise), and D is a giventime interval for the guidance generation. The tilde means anestimated value of corresponding parameter. For the sake ofsimplicity, let assume the network operator tries to generate theguidance for ith interval with information of (i-1)th interval.Firstly, the network operator distinguishes the guided and non-guided traffic by subtracting glki−1 from slki−1 after calculatingglki−1 based on the peer reports. Then, the network operatorcan estimate nglki by applying the existing traffic estimationtechnique to nglki−1. For example, with the sliding windowof recent N intervals [4], nglki is 1

N

∑i−1j=i−N nglkj . Finally,

the network operator can estimate glki by subtracting nglkifrom clk ∗ D (that is a total allowable traffic volume duringith interval). Through this way, the network operator may beable to calculate the estimated allowable guided traffic as theguidance without the guidance dependency problem.

To use this peer-aided approach, an appropriate techniqueshould be applied to block false reports by malicious peers.For this, we may be able to utilize existing reputation man-agement system like [13] requiring irrefutable proof of eachtransaction since the peer report is about transaction betweenpeers. Irrefutable proof (that can be implemented using digitalsignature) can be used to mitigate the fabrication of the reportby requiring all the report to be associated with proof of avalid transaction.

V. CONCLUSION

Our contributions in this paper are two-fold. First, weinvestigate the performance of the existing network operator-friendly P2P traffic control techniques in intra-domain. Oursimulation results show that the performance-based techniquereduces the traffic overhead even though it shows slightlylonger content download path compared to the distance-based technique. In addition, the performance-based techniqueenables the guided peers to avoid the highly utilized links.However, the performance-based technique has the guidancedependency problem that can block finer-grained traffic con-trol. Second, based on our observations above, we set theguideline aiming to resolve the traffic oscillation problem.

We are currently developing the network operator-friendlytraffic control approach adopting our guideline. Especially, wefocus on a way to estimate and utilize the allowable guidedtraffic volume in an efficient and effective way. It would alsobe interesting to study about an efficient way to block falsereport in a distributed manner.

ACKNOWLEDGEMENT

This research was partially supported by the MKE (TheMinistry of Knowledge Economy), Korea, under the ITRC(Information Technology Research Center) support programsupervised by the NIPA (National IT Industry PromotionAgency) (NIPA-2010-(C1090-1011-0004)).

REFERENCES

[1] T. Karagiannis, D. Papagiannaki, and M. Faloustsos, “Should internetservice providers fear peer-assisted content distribution?” in Proc. of IMC,2005.

[2] B. Choen, “Incentives build robustness in bittorrent,” in Proc. of Workshopon Economics of Peer-to-Peer Systems (P2PEcon), 2003.

[3] H. Xie, Y. Yang, A. Krishnamurthy, Y. Liu, and A. Silberschatz, “P4P:Provider portal for applications,” in Proc. of ACM SIGCOMM, 2008.

[4] H. Xie, Y. Yang, and A. Silberschatz, “Towards an isp-compliant, peer-friendly design for peer-to-peer networks,” IFIP Networking, LNCS 4982,pp.375-384, 2008.

[5] V. Aggarwal, A. Feldmann, and C. Scheideler, “Can isps and p2p userscooperate for improved performance?,” SIGCOMM Computer Communi-cation Review, vol. 37, no. 3, 2007.

[6] D. Saucez, B. Connet, and O. Bonaventure, “Implementation and pre-liminary evaluation of an isp-driven informed path selection,” in Proc. ofACM CoNEXT, Dec. 2007.

[7] D. Choffnes and F. Bustamante, “Taming the torrent: A practical approachto reducing cross-isp traffic in peer-to-peer systems,” in Proc. of ACMSIGCOMM, 2008.

[8] C. H. Hsu and M. Hefeeda, “ISP-friendly peer matching without ispcollaboration,” in Proc. of International Workshop on Real Overlays andDistributed Systems (ROADS), 2008.

[9] J. A. Pouwelse, P. Garbacki, D. H. J. Epema, and H. J. Sips, “Thebittorrent p2p file sharing system: Measurements and analysis,” in Proc.of International Workshop on Peer-to-Peer Systems (IPTPS), 2005.

[10] A. Legout, N. Liogkas, E. Kohler, and L. Zhang, “Clustering and sharingincentives in bittorrent systems,” in Proc. of ACM SIGMETRICS, 2007.

[11] R. Bindal, P. Cao, W. Chan, J. Medval, G. Suwala, T. Bates, andA. Zhang, “Improving traffic locality in bittorrent via biased neighborselection,” in Proc. of IEEE ICDCS, 2006.

[12] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and Y. R. Yang,“Application-layer traffic optimization (ALTO) requirements,” Internet-Draft draft-ietf-alto-reqs-00 (Work in Progress), April 2009.

[13] M. Srivatsa, L. Xiong, and L. Liu, “TrustGuard: Countering vulnera-bilities in reputation management for decentralized overlay networks,” inProc. of ACM WWW, 2005.

[14] L. Jun, Z. Shunyi, L. Shidong, and X. Ye, “Active p2p traffic iden-tification technique,” in Proc. of IEEE Computational Intelligence andSecurity, 2007.

[15] Network Simulator ns-2, http://www.isi.edu/nsnam/ns/.[16] IsoHunt, http://isohunt.com/.[17] Team Cymru, http://www.team-cymru.org/.[18] FixedOrbit, http://www.fixedorbit.com/.[19] Rocketfuel, http://www.cs.washington.edu/research/networking/rocketfuel/.

102