On the impact of user mobility on peer-to-peer video streaming

IEEE Wireless Communications • December 200854 1536-1284/08/$25.00 © 2008 IEEE

x

xB

A

R2

L

PR A C T I C A L AS P E C T S OF MO B I L I T Y I N

WIREL E S S SE LF -OR G A N I Z I N G NETWORKS

INTRODUCTIONWireless networks are a key technology to pro-vide user mobility. Wireless mesh networks(WMNs) are self-organizing networks based ona backbone of stationary wireless routers thatcooperatively provide Internet access to mobileusers. Moreover, WMNs are a low-cost alterna-tive, compared to traditional cabled networks, toextend the Internet. Recently, a large number ofresearch centers and universities [1] began tomake stronger efforts to deploy WMNs, provid-ing ubiquitous Internet access on campuses andin cities.

Mobility is one of the main reasons for usingwireless networks. As entertainment and newsupdates are a part of our daily lives, users wantaccess to streaming audio and video applications

while on the move in areas illuminated by aWMN. In such cases, the application perfor-mance perceived by users is affected by variablenetwork connectivity, caused by various factorssuch as handoffs between routers, varying levelsof interference, or protocol reconfiguration.Therefore, it is of utmost importance to evaluatethe impact of user mobility on the performanceof different protocols and applications in realscenarios.

In this article, we focus on peer-to-peer (P2P)applications, which are a great success in theInternet and in community networks. In P2Papplications, all nodes collaborate to provide thefunctionalities of the application. The decentral-ized P2P architecture increases scalability andprovides resilience to node failures [2]. Morerecently, P2P techniques are being successfullyused for live media streaming [3]. Applicationssuch as SopCast allow a TV channel, radio sta-tion, or stored video to be publicly available inthe Internet. In P2P video applications, all nodescan send or receive media simultaneously. Thiscooperative environment is completely differentfrom typical TV and radio broadcasting systems,which are based on the client-server model.

Practical mobility aspects play an importantrole in analyzing the utility of P2P video stream-ing applications, especially when compared totraditional client-server applications. In this arti-cle, we investigate the behavior of popular P2Pvideo streaming applications in a scenario wherea person walks in an area covered by a WMN.Using a WMN testbed, we analyze the impact ofmobility on the performance of differentP2Papplications, identifying some of the practicalproblems that arise.

This article is organized as follows. The nextsection indicates the main characteristics of fiveof the most popular P2P video applications inthe Internet. Then, we identify practical aspectsof handling user mobility in WMNs. We thendescribe our experimentation scenario and dis-

IGOR M. MORAES, MIGUEL ELIAS M. CAMPISTA, LUI’S HENRIQUE M. K. COSTA, AND

OTTO CARLOS M. B. DUARTE, UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

JAIRO L. DUARTE, DIEGO G. PASSOS, AND CÉLIO VINICIUS N. DE ALBUQUERQUE, UNIVERSIDADE FEDERAL FLUMINENSE

MARCELO G. RUBINSTEIN, UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO

ABSTRACTWireless mesh networks are emerging as apromising solution for ubiquitous Internet accesswith mobility support. In such networks, usermobility may lead to Internet gateway changesand consequently, impact the performance ofcontinuous media applications. In this article, weinvestigate the impact of user mobility on theperformance of peer-to-peer video applicationsover wireless mesh networks. Peer-to-peer videostreaming applications rely on the collaborativebehavior of peers to assist the source in deliver-ing multimedia content, reduce costs, andincrease the scalability of video distribution. Weidentify practical issues related to mobility forP2P video streaming implementation in WMNs,such as addressing and forwarding strategies.Furthermore, we evaluate the performance ofdifferent P2P streaming applications as the userwalks in our WMN testbed. Results indicatemobile users benefit from the frequent short-lived connections established in modern P2Pvideo sessions.

ON THE IMPACT OF USER MOBILITY ONPEER-TO-PEER VIDEO STREAMING

The authors investigate theimpact of user mobility on the performance of peer-to-peer videoapplications overwireless mesh networks.

MORAES LAYOUT 12/3/08 1:54 PM Page 54

IEEE Wireless Communications • December 2008 55

cusses the performance measurements obtained.The final section includes the conclusions of thearticle and identifies open research issues.

PEER-TO-PEER VIDEO STREAMING

Video streaming in the Internet has become apopular service in recent years. Nevertheless,video streaming is still a costly service because ofthe high bandwidth requirements and the hugenumber of potential users. Currently, P2P videostreaming is emerging as a promising solutionfor video distribution in the Internet. In thesesystems, peers must share their resources toassist the server in delivering the video. The keyidea is the same as for a P2P file-sharing system,but whereas file-sharing systems target elasticdata transfers, streaming systems focus on theefficient delivery of multimedia content understrict bandwidth and timing requirements.

DATA DELIVERYP2P video streaming applications are classifiedaccording to the type of distribution graph theybuild [2]. Tree-based overlays use tree distribu-tion graphs, where the root is the video source.Each node joins the tree and then receives datafrom a parent node, the source, or a peer whosubscribed previously. The main advantages ofthe tree topology are low latency and low-con-trol overhead when peer changes are rare. Onthe other hand, when peer changes are frequent,control overhead is high because the tree mustbe reconstructed upon each change. Moreover,discontinuities in reception may happen, andtherefore, peers must buffer video packets dur-ing the tree reconstruction to avoid losing con-tent. In mesh-based overlays, a mesh topology isused. Data is divided into chunks, and each peerexchanges information about its own chunkswith a subset of peers. A peer can downloadchunks from several peers concurrently, makingthe mesh topology less sensitive to peer failuresand departures. Nevertheless, control overheadtends to be higher because peers must exchangechunk maps to request content from other peers.Moreover, service performance depends on thebuffer size of the nodes because video chunksthat might be received out of order must bestored.

P2P VIDEO APPLICATIONSWe have chosen five of the currently most popu-lar P2P video streaming applications, namelyend system multicast (ESM), PPLive, SopCast,PPStream, and TVAnts.1 ESM uses tree-baseddata delivery, whereas the other applicationsemploy a mesh topology.

ESM [4] was one of the first P2P video appli-cations to appear. Actually, the original goal ofESM was to implement multicast functionalitiesin the end systems instead of the routing layer.A part of the system called Narada creates amesh topology that interconnects the participat-

ing nodes according to estimation of round-triptime (RTT) between nodes. From this topology,a distribution tree is created, where the root isthe video source and branches are low-latencylinks up to the leaves. ESM is one of the fewP2P video applications that are open source.

PPLive, SopCast, PPStream, and TVAnts areproprietary, with no specification or source codeavailable. They all use a mesh-based architectureand work similarly to BitTorrent. A node sub-scribes to the system and receives addresses of aset of super nodes, which are nodes responsibleof keeping track of peers that already download-ed or currently are downloading a specific videochunk. When a node is in contact with peersindicated by a super node, the node receives abuffer map from each of them, containing thevideo chunks that the peer has. After receivingthe maps, the node chooses a subset of peers torequest the video chunks from.

Currently, PPLive is probably the most popu-lar P2P video streaming application. The majordifference between PPLive and BitTorrent is thetime requirements PPLive must guarantee. Sop-Cast is also very popular, partially because of theservices it provides to producers of content. InSopCast, anyone is allowed to register andbroadcast a TV channel in the Internet.PPStream and TVAnts also are gaining popular-ity among users.

P2P streaming applications use differenttransport protocols and depending on those pro-tocols, they are more or less adapted to mobility.ESM uses TCP Friendly Rate Control (TFRC)as a transport protocol, which is rate-controlledUser Datagram Protocol (UDP) and achievesTCP-friendly throughputs [4]. Given that mostP2P applications are not open source, trafficmonitoring has been performed [2, 5]to identifythe transport protocols used. Silverston andFourmaux [5] classify transport protocols accord-ing to the type of traffic (video or signaling).PPLive uses TCP for video transmission andTCP and a few UDP datagrams for signaling.SopCast uses primarily UDP for most of itsfunctions but also makes use of a few TCP con-nections. PPStream relies only on TCP, whereasTVAnts uses both TCP and UDP for videotransmission and signaling. The main character-istics of the cited applications are summarized inTable 1.

One would expect that applications that

nn

Table 1. Main characteristics of the analyzed P2P applications.

Application Data deliverystructure

Transportprotocol

Sourcecode

Ownchannelbroadcast

SopCast Mesh-based UDP/a few TCP Proprietary Yes

PPLive Mesh-based TCP/a few UDP Proprietary No

TVAnts Mesh-based TCP/UDP Proprietary No

PPStream Mesh-based TCP Proprietary No

ESM Tree-based TRFC Open source Yes

1 The applications can be downloaded fromhttp://esm.cs.cmu.edu, http://www.pplive.com/en,http://www.sopcast.org, http://www.ppst ream.cn, andhttp://tvants.en.softonic.com


IEEE Wireless Communications • December 200856

strongly rely on the use of TCP would face prob-lems in our mobile wireless mesh scenario. Theconnection- oriented nature of TCP, coupledwith its congestion control mechanism turns itsadaptation to wireless networks non-trivial[6].However, the nature of P2P video sessions isbased on a large number of short-lived TCP con-nections, and we claim that this feature fitsmobile scenarios well.

WIRELESS MESH NETWORKS

WMNs are a cost-effective alternative for ubiq-uitous network access given their user mobilitysupport and low installation cost. Currently,WMNs are being widely deployed in cities, uni-versity campuses, commercial buildings, andunderserved communities. WMNs are character-ized by the presence of a backbone, typicallycomposed of stationary wireless routers, whichprovide backhaul access to nodes not withinrange of gateways to the wired infrastructureand interconnect isolated LANs. The backboneuses multihop communications to maintain net-work connectivity and to forward traffic to andfrom users.

In WMNs, users are potentially mobile andconnect to the backbone through routers playingthe role of access points. During handoff, net-work connectivity may be interrupted and per-formance of protocols degraded [7]. Thehand-off duration typically depends on theaddressing scheme and the forwarding strategyemployed by WMNs, as discussed in the follow-ing sections.

ADDRESSINGAddressing is a challenging issue for mobile net-works. The address modifications and the use ofprivate IP addresses impact the protocols perfor-mance, possibly leading to connectivity lossesand application disruptions.

Private IP Versus Public IP — From data collectedin 2005, more than 50 percent of broadbandusers in the United Kingdom and in the UnitedStates are behind network address translator(NAT) devices [8].

One problem related to the use of NATs isthat computers accessing the Internet usingNAT devices can make outbound connections tocomputers with public IPs, but typically cannotreceive inbound connections. Furthermore, whena computer that is behind a NAT device movesto a new location that is also served by anotherNAT device, TCP connections may be brokenbecause of the time required to reconfigure portmapping. Consequently, applications may sufferwith packet losses and disruptions.

In P2P streaming applications, all participat-ing nodes must be bidirectionally reachable. AsNAT often prevents peers from establishing con-nections with each other, the efficiency of videodistribution is seriously impacted.

Currently, most P2P applications rely onmanual port configuration to enable communica-tion between peers behind NAT devices. Never-theless, some techniques were proposed toenable peer-to-peer TCP applications. Most ofthem are based on layering another address on

top of the IP address. For example, the SimpleTraversal of UDP through NAT (STUN) proto-col [9]and its TCP version (STUNT) [10] use theSession Initiation Protocol (SIP) uniformresource indicator (URI) to communicate with aSTUN/STUNT server first. Then, the serverreports the public IP address of the NAT device,and what port is opened by the NAT device backto the STUN/STUNT client to enable incomingtraffic. Although a number of techniques to tra-verse NAT devices exist, none of them is ideal ina mobility scenario and, as a consequence, thecoexistence of NAT and mobility remains anopen issue.

Dynamic IP Versus Fixed IP — Internet applicationsassume that the IP address of a given node doesnot change during long periods of time. Thisassumption, however, does not hold for mobilenetworks because mobile users can changeaddresses as they move from one network toanother. Thus, established connections do notsurvive the address change because they rely onfixed source and destination IP addresses. If themobile user uses a dynamic IP, the applicationmay experience connectivity losses during theprocess of acquiring a new IP address. On theother hand, if the mobile user has a fixed IPaddress, his address must be kept through tun-nels to support the active connections, for exam-ple, using mobile IP. In the WMN scenario, analternative to tunneling is to run an ad hoc rout-ing protocol in each mobile user.

Usually, WMNs use routing protocols to for-ward data. Each node maintains a routing tableto forward packets correctly. If a user node thatis also running a routing protocol moves acrossthe backbone, the topology changes, and thusthe routing tables should be updated. If themobile user has a fixed IP, the handoff is impact-ed only by the convergence time of the routingprotocol. On the other hand, if the mobile useruses dynamic IP, the time to acquire a new IPaddress or to establish a tunnel should be addedto the convergence time.

VIDEO STREAMING IN WMNS

In this section, we present the results of ourexperiments. First, we evaluate the performanceof a client-server application under client mobili-ty. Then, we analyze the behavior of differentP2P applications in the same scenario. Our mea-surements were collected in an indoor testbed atthe GTA laboratory of the Federal University ofRio de Janeiro, Brazil. The testbed is composedof two desktops, one laptop, and five wirelessrouters. The desktops are equipped withIEEE802.11b/g PCI wireless interfaces withexternal omnidirectional antennas and Fast Eth-ernet cards. The laptop is equipped with anIEEE802.11b/g PCMCIA wireless card. The twodesktops play the role of gateways providingInternet access to the mobile user. Both desk-tops run Debian Linux OS, and the laptop runsWindows XP because most P2P applications arenot implemented in Linux. For the client-serverexperiments, another desktop running WindowsVista, connected to the gateways through awired network, is used as a server. The wireless

WMNs are a cost-effective alternative for ubiquitous networkaccess given theiruser mobility supportand low installationcost. Currently,WMNs are beingwidely deployed incities, university campuses, commercialbuildings, and underserved communities.



routers are LinkSysWRT54G running LinuxOpenWRT. These wireless routers and the twogateways form the WMN backbone.

In our experiments, we launch a packet snif-fer on the laptop and on the desktops. After-ward, we start the P2P application and select aTV channel or start the client-server application.To evaluate the impact of user mobility, we limitour analysis to the events that occur inside theWMN, by comparing the traffic that arrives atthe gateways with that of the laptop. As soon asthe application buffer becomes full, this warm-up phase is ended, and a person carrying thelaptop starts walking from point A to point Dand then comes back to A (Fig. 1). The goal ofthis mobility scenario is to reproduce a userwalking through different gateways. We expectwith this mobility scenario that the user willexperience a change of Internet gateway at leasttwice, from GW1 to GW2 and then again toGW1, on his way back. Upon returning to pointA, we quit the application, enter the terminationphase, and stop all packet sniffers.

All testbed nodes use IEEE 802.11g in ad hocmode and run the Optimized Link-State Routing(OLSR) protocol with the expected transmissioncount (ETX) routing metric. The gatewaysannounce default routes using host and networkassociation (HNA) messages implemented inOLSR. Therefore, the laptop chooses the gate-way according to the path computed by the rout-ing protocol. In our testbed, the laptop uses afixed, private IP address. Thus, the gateways useNAT to enable users to access the Internet. Wehave fixed the IP address of the laptop to avoidDynamic Host Configuration Protocol (DHCP)delays.

The video server used in the client-serverexperiments is a PC running the VLC applica-tion configured with HTTP. The mobile useralso runs VLC. The video in the server was pre-viously recorded from a SopCast channel toguarantee that the videos used in the experimenthave similar rates.

We use four P2P video streaming applica-tions in our tests: SopCast (version 2.0.4),PPStream (version 2.2.25), PPLive (version1.9.21), and TVAnts (version 1.0.0.59). We donot include the results of ESM because it wasnot able to connect to any channel at the timewe performed the measurements. We performfive measurements with each application usingpopular channels: TVMacumb@ for SopCast,HunanTV for PPStream and PPLive, andCCTV-1 for TVAnts. The video streams haverates between 350 and 400 kb/s.

In addition to network performance metrics,we conduct a subjective analysis to verify thequality of the video reception on the mobileclient. First, we record the video stream receivedby the mobile client, which is called user sample.We also record the video stream received by auser placed at the same wired network of thetwo gateways, called reference sample. The userand the reference samples are shown to an audi-ence of 30 spectators. Each spectator gives a rat-ing from 1 to 5, where 5 is the best, according tothe perceived quality of the video.

As previously mentioned, according to thetransport protocol used, the applications behave

differently in the presence of client mobility andNAT. In the following, we focus on the measure-ments obtained with SopCast and PPStream,which are representative of applications basedon UDP and TCP, respectively. Results obtainedwith all applications are summarized in Table 2.We analyze both download and upload traffic.

CLIENT-SERVER APPLICATIONFigure 2 shows the performance of the client-server application when the client is stopped ormoving. Points A to D in Fig. 2b show theinstants where the client crosses the trajectorylandmarks of Fig. 1. The black dots on the X-axis mark the instants where the gatewaychanges. In both scenarios, the client establishesonly one TCP connection with the server. Whenthe client is static, this connection is active dur-ing the whole experiment (Fig. 2a). On the otherhand, when the client is mobile, the number ofTCP segments received rapidly decreases justafter the first gateway change. After a few sec-onds, the TCP connection ends, as indicated inFig. 2b, stopping the video reception. For thiscase, the audience gives a score equal to 3.68(with standard deviation σ = 0.75) for the refer-ence sample and equal to1.35 (σ = 0.55) for theuser sample, showing that the client-server appli-cation is not well suited for mobile environ-ments. By relying on just one connection, theapplication disrupts because the server resets theconnection. On the other hand, a P2P applica-

nn

Figure 1. Trajectory of the experiment.

xx

x

xB

C D

A

10 m

10 m

3 m

15 m 5 m

R3

GW1

R1

R5GW2

R2R4

L



tion that continuously establishes new short-livedconnections and maintains multiple active con-nections is more suitable for mobile environ-ments, as the performance analysis in the nextsections demonstrates.

P2P TCP-BASED APPLICATION: PPSTREAMFigure 3 presents the results of one experimentrun with PPStream, an application that uses onlyTCP as a transport protocol. All figures exceptFig. 3d show the performance of the applicationduring the movement from point A to D andthen back to point A. As expected, PPStream isthe application most sensitive to gatewaychanges. Figure 3a plots the number of TCP seg-ments received per second during the experi-ment. We can see that there is a period duringwhich the routing protocol is adapting to theclient’s movement. As routes are recomputed,there are more than two gateway changes, eventhough the client keeps walking in a scenariowith only two gateways. We can observe that thenumber of received TCP segments sharplydecreases, sometimes reaching zero. Figure3bplots the cumulative number of TCP bytesreceived by the client as it moves across theWMN gateways. The reference curve plots thecumulative number of bytes transmitted by thegateways without taking into account retransmis-sions, whereas the measured curve shows thecumulative number of bytes received by theclient including retransmissions. When the num-ber of transmission failures in the wireless net-work is higher, the curves are farther from eachother. The plateaus occur when the TCP con-nections are stale. Figure 3c plots the beginning(crosses) and the end (triangles) of each TCPconnection. As the warm-up and the terminationphases are omitted in this figure, some connec-tions are already opened before the start ofmovement, and others are not closed before theend of the movement. The fact that most of theTCP connections are short-lived contributes tothe robustness of P2P applications, where peersmay enter or leave the network at any time.

These short-lived connections are better illus-trated in Fig. 3d, which plots the cumulative dis-tribution function of TCP connection durationsincluding warm-up and termination phases. P2Pstreaming applications also benefit from short-lived connections to handle user mobility.Because the data stored in the application buffercomes from numerous connections, and only afew of them are active and therefore, affectedwhen the gateway changes, the video streamingis not severely impaired. The audience, in thiscase, rates the reference sample with 4.08 (σ =0.68) and the user sample with 2.45 (σ = 0.77).It is also worth noting that during gatewaychanges, the rate of new connection openingsdecreases. Figure 3e plots the interarrival timeof received TCP segments. We observe that dur-ing gateway changes, the number of receivedsegments decreases as the time between succes-sive receptions grows. In the case of TCP, itscongestion control also contributes to reduce thesource transmission rate. Because peers also actas servers, we also analyze upload traffic traces.Figure 3f shows that TCP traffic also suffers withtransmission failures in the upload direction.

P2P UDP-BASED APPLICATION: SOPCASTFigure 4 presents the results of one experimentrun with SopCast, which mostly uses UDP. Typi-cally, UDP-based applications have shown fewerlosses because of gateway changes compared toTCP-based applications. Even though there arelosses when the gateway changes, the receiveddata do not reach zero as seen in the experimentplotted in Fig. 4a. With SopCast, the video didnot freeze as opposed to the TCP-based applica-tion (PPStream). The audience gives a scoreequal to 3.77 (σ = 0.62) for the reference sam-ple and equal to 3.24 (σ = 0.62) for the usersample. This behavior is also reflected in thecumulative plot of UDP datagrams presented inFig. 4b. In this figure, the reference curve plotsthe cumulative number of bytes sent by bothgateways and the measured curve plots thecumulative number of bytes received by the

nn

Table 2. Experiment summary.

Applications

SopCast PPLive TVAnts PPStream

Experiment duration (s) 80.80 (σ = 1.56) 79.62 (σ = 0.52) 78.25 (σ = 3.75) 78.27 (σ = 5.02)

Number of source peers(UDP/TCP)

110.40 (σ = 15.07)/1.00 (σ = 0.63)

104.25 (σ = 4.81)/60.75 (σ = 6.53)

32.20 (σ = 2.40)/13.40 (σ = 1.62)

— /48.4 (σ = 3.20)

UDP deliv. ratio (%)(download/upload)

79.53 (σ = 16.44)/99.99 (σ = 0.01)

66.18 (σ = 2.87)/99.80 (σ = 0.33)

66.46 (σ = 1.59)/98.82 (σ = 0.97)

— / —

TCP retrans. ratio (%)(download/upload)

62.50 (σ = 41.46)/100.00 (σ = 0.00)

93.92 (σ = 2.07)/97.31 (σ = 1.23)

92.48 (σ = 4.40)/95.63 (σ = 2.03)

97.47 (σ = 0.70)/95.73 (σ = 2.70)

Number of gateway changes 6.40 (σ = 2.58) 10.00 (σ = 2.06) 8.00 (σ = 1.67) 8.00 (σ = 3.58)

Rate of new connec./flows0.03 (σ = 0.01)/0.84 (σ = 0.02)

1.90 (σ = 0.01)/1.07 (σ = 0.01)

0.51(σ = 0.01)/0.31 (σ = 0.01)

1.44 (σ = 0.05)/ —



client. Note that these curves do not presentlong plateaus as Fig. 3b. Figure 4c plots thebeginning and the end of different UDP flowsreceived by the mobile client. Figure 4d presentsthe cumulative distribution function of UDPflow durations. As for TCP connections inPPStream, most of the UDP flows are short-lived, which means that fewer flows suffer withgateway changes. Also of importance is that theinterarrival time between UDP datagrams is lesssensitive to gateway changes than in the case ofTCP-based applications (Fig. 3e and Fig. 4e). Incontrast to TCP-based applications, gatewaychanges do not result in upload traffic losses inapplications that mostly use UDP as the trans-port protocol, as seen in Fig. 4f. This is becauseregardless of using NAT or not, the IP addressof the destination peer remains the same evenwhen the user changes the associated gateway.Therefore, after the datagrams sent by themobile user are received by at least one gateway,the delivery rate is not affected. Otherwise in thedownload direction, Internet peers must changethe destination IP address to the new associatedgateway as the user moves. In this case, the des-tination IP address is equal to the address of theassociated gateway using NAT. This operationcan take time, often resulting in transmissionfailures, independent of the transport protocol.As TCP traffic is bidirectional, the traffic isaffected by user mobility even when data istransmitted in the upload direction. Hence, thecombination of gateway changes, NAT, and TCPalways results in transmission failures when seg-ments are sent to the previous associated gate-way.

SUMMARY OF THE EXPERIMENTSTable 2 summarizes the measurements obtainedwith SopCast, PPStream, PPLive, and TVAnts.Each measurement was repeated five times foreach application. Table 2 shows the average andthe standard deviation of some measurements ofinterest. In our experiments, the number ofUDP sources of SopCast is higher than the num-ber of TCP sources of PPStream. Nevertheless,UDP sources in PPStream were not observed,

and TCP sources in SopCast are often observedat the beginning of each experiment. The UDPdelivery ratio is defined as the number of UDPdatagrams transmitted by the gateways dividedby the number of UDP datagrams received bythe mobile node. With TCP sources, computingthe delivery ratio is not straightforward becausea segment is retransmitted until it is delivered,or a timeout occurs. Therefore, a segment losswould happen only after multiple retransmis-sions. In addition, retransmissions also can becaused by lost acknowledgments. Because in ourscenario we would like to measure transmissionfailures, we define the TCP retransmission ratioas the number of first attempts to send a seg-ment divided by all attempts, including possibleretransmissions. Note that the delivery ratio ofUDP datagrams in the download direction is themost affected because sources do not use con-gestion control algorithms as in the TCP case.On the other hand, in the upload direction, thedelivery ratio is high, confirming the resultsshown previously. TCP traffic presents transmis-sion failures in both download and upload direc-tions because it is bidirectional, and the client isbehind a NAT device. The number of gatewaychanges is similar for all applications because itdepends on the routing protocol, which is thesame in all experiments. Moreover, the rate ofnew connections or flows per second contributesto the robustness of the applications in mobilescenarios.

CONCLUSION

In this article, we have investigated the feasibili-ty of P2P video streaming applications runningon WMNs. P2P streaming is already a huge suc-cess in the Internet due to its decentralizednature and larger scalability when compared toserver-based video distribution. Moreover,WMNs are an enabling technology for ubiqui-tous access to the Internet. Nevertheless, as wehave indicated, there are various open issues ondealing with practical aspects of mobile P2Pstreaming using WMNs.

The first part of this article outlined practical

nn

Figure 2. Network measurements with client-server application: a) client is stopped; b) client is moving.

Time (s)

(a)

2000

10

Num

ber

of s

egm

ents

rec

eive

d

20

30

40

50

60

70

80

40 60 80Time (s)

Landmarks

(b)

2000

10Num

ber

of s

egm

ents

rec

eive

d

20

30

40

50

60

70

80C D C B ABA

40

End of TCP connection

60 80

Gateway change



issues related to addressing and to the forward-ing strategy used. Then, we described our experi-ments with four of the most popular P2P videostreaming applications, namely, SopCast, PPLive,PPStream, and TVAnts. We collected traffictraces from those applications running in aWMN testbed in our laboratory. The analysis ofthose traces has shown that UDP-based applica-tions enable a smooth adaptation to the WMN

environment. Nevertheless, applications that useTCP connections also can be feasible, especiallyif using numerous short-lived connections. Theuse of short-lived connections is a characteristicof P2P streaming applications, where peersreceive media content from multiple sources.Thus, the P2P distributed architecture can con-tribute to video streaming, independent of thetransport protocol.

nn

Figure 3. Network measurements with PPStream: a) TCP segments received; b) cumulative TCP bytes received; c) TCP connectionsduration; d) CDF of TCP connections duration; e) TCP segments interarrival time; f) cumulative TCP bytes sent.

Time (s)40

(a)

00

50

Num

ber

of s

egm

ents

rec

eive

d

100

150

200

250

20 60

BCDC

Landmarks

BA A

Time (s)40

(b)

00

0.2

Cum

ulat

ive

data

(M

byte

s)

0.1

0.3

0.5

0.4

0.6

0.7

20 60

BCDC

Landmarks

BA A

Time (s)40

(e)

00

500

Inte

rarr

ival

tim

e (m

s)

1000

1500

2000

2500

3000

3500

20 60

BCDC

Landmarks

BA A

Time (s)40

(f)

00

Cum

ulat

ive

data

(M

byte

s)

0.02

0.04

0.06

0.08

0.1

20 60

BCDC

Landmarks

BA A

Time (s)40

(c)

00

50

TCP

conn

ecti

on n

umbe

r

100

150

250

20 60

BCDC

Landmarks

BA A

Connected duration (min)

(d)

00

Cum

ulat

ive

dist

ribu

tion

of

conn

ecti

ons

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0.5 1 1.5 2 2.5 3 3.5

Gateway change

Gateway change

Start of connectionEnd of connectionGateway change

MeasuredReferenceGateway change

MeasuredReferenceGateway change



ACKNOWLEDGMENT

The authors would like to thank CNPq, CAPES,Faperj, and FUJB for partially funding thisresearch.

REFERENCES[1] M. E. M. Campista et al., “Routing Metrics and Proto-

cols for Wireless Mesh Networks,” IEEE Network, vol.22, no. 1, Jan. 2008, pp. 6–12.

[2] A. Sentinelli et al., “Will IPTV Ride the Peer-to-Peer Stream?”IEEE Commun. Mag., vol. 45, no. 6, June 2007.

[3] D. A. G. Manzato and N. L. S. da Fonseca, “An Incen-tive Mechanism for Peer-to-Peer Networks with LiveStreaming,” IEEE GLOBECOM, Nov. 2006.

[4] Y.-H. Chu et al., “A Case for End System Multicast,”IEEE JSAC, vol. 20, no. 8, 2002, pp. 1456–71.

[5] T. Silverston and O. Fourmaux, “Measuring P2P IPTVSystems,” Int’l. Wksp. Net. Op. Sys.Support for DigitalAudio and Video, June 2007.

[6] A. A. Hanball, E. Altman, and P. Nain, “A Survey of TCP

nn

Figure 4. Network measurements with SopCast: a) UDP datagrams received; b) cumulative UDP bytes received; c) UDP flows dura-tion; d) CDF of UDP flows duration; e) UDP datagrams interarrival time; f) cumulative UDP bytes sent.

Time (s)40

(a)

00

50

Num

ber

of d

atag

ram

s re

ceiv

ed

150

100

200

250

20 60

BCDC

Landmarks

80

BA A

Time (s)40

(b)

00

7

Cum

ulat

ive

data

(M

byte

s)

6

5

4

2

3

1

8

20 60

BCDC

Landmarks

80

BA A

Time (s)40

(e)

00

150

Inte

rarr

ival

tim

e (m

s)

100

50

250

200

400

450

300

350

20 60

BCDC

Landmarks

80

BA A

Time (s)40

(f)

00

0.25

Cum

ulat

ive

data

(M

byte

s)

0.2

0.15

0.1

0.05

0.3

60

BCDC

Landmarks

8020

BA A

Time (s)40

(c)

00

40UD

P flo

w n

umbe

r

20

100

80

60

120

140

20 60

BCDC

Landmarks

80

BA A

Flow duration (min)1

(d)

00

0.7

Cum

ulat

ive

dist

ribu

tion

of

flow

s

0.8

0.9

0.6

0.5

0.4

0.3

0.2

0.1

1

1.50.5 2 2.5 3

Gateway change MeasuredReferenceGateway change

Start of flowEnd of flowGateway change

Gateway change MeasuredReferenceGateway change



Over Ad Hoc Networks,” IEEE Commun. Surveys &Tutorials, vol. 7, no. 3, 2005, pp. 22–36.

[7] Y. Amir et al., “Fast Handoff for Seamless WirelessMesh Networks,” ACM Mobisys, June 2006, pp. 83–95.

[8] P. Rodriguez, S.-M. Tan, and C. Gkantsidis, “On the Fea-sibility of Commercial, Legal P2P Content Distribution,”ACM SIGCOMM Comp. Commun. Rev., vol. 36, no. 1,Jan. 2006, pp. 75–78.

[9] J. Rosenberg et al., “STUN-Simple Traversal Of UserDatagram Protocol (UDP) through Network AddressTranslators (NATs),” IETF Net. Working Group RFC3489, Mar. 2003.

[10] S. Guha, Y. Takeda, and P. Francis, “NUTSS:ASIP-BasedApproach to UDP and TCP Network Connectivity,” ACMSIGCOMM, Aug. 2004.

BIOGRAPHIESIGOR M. MORAES [S‘08] received his electronic engineer andM.Sc. degrees in electrical engineering from the FederalUniversity of Rio de Janeiro (UFRJ), Brazil, in 2004 and2006, respectively. Since March 2006 he has been a D.Sc.student with GTA/COPPE/UFRJ. His major research interestsare in peer-to-peer video streaming, security, wireless net-works, and optical networks.

MIGUEL ELIAS M. CAMPISTA [S‘05] received a telecommunica-tions engineering degree from Fluminense Federal Universi-ty (UFF), Rio de Janeiro, Brazil, in 2003 and an M.Sc.degree in electrical engineering from UFRJ in 2005. Cur-rently, he is a D.Sc. student with GTA/COPPE/UFRJ. Hismajor research interests are in multihop wireless networks,quality of service, wireless routing, and home networking.

JAIRO L. DUARTE received B.Sc. and M.Sc. degrees in comput-er science from UFF in 2004 and 2008 respectively. Cur-rently, he is on an internship program at Siemens CorporateResearch, Princeton, New Jersey. His major research inter-ests are wireless networks and client mobility.

DIEGO G. PASSOS received a B.Sc. degree in computer sci-ence from UFF in 2007. Currently, he is an M.Sc. student atUFF. His major research interests are multihop wireless net-works and wireless routing.

LUI’S HENRIQUE M. K. COSTA [M‘99] received his electronicengineer and M.Sc. degrees in electrical engineering fromUFRJ in 1997 and 1998, respectively, and a D.Sc. degreefrom the University Pierre et Marie Curie (Paris 6), Paris,France, in 2001. Since August 2004 he has been an associ-ate professor with COPPE/UFRJ. His major research interestsare in the areas of routing, wireless networks, and groupcommunications. He has been a member of the Associationfor Computing Machinery since 2001.

MARCELO G. RUBINSTEIN [S‘95, M‘03] received an B.Sc. degreein electronics engineering, and M.Sc. and D.Sc. degrees inelectrical engineering from UFRJ in 1994, 1996, and 2001,respectively. From January to September 2000 he was atthe PRiSM Laboratory, University of Versailles, France. He isnow an associate professor with Universidade do Estadodo Rio de Janeiro (UERJ). His major interests are in wirelessnetworks, home networking, medium access control, andquality of service.

CÉLIO VINICIUS N. DE ALBUQUERQUE [S‘94, M‘00] received B.S.and M.S. degrees in electrical and electronics engineeringfrom UFRJ in 1993 and 1995, and M.S. and Ph.D. degreesin information and computer science from the University ofCalifornia at Irvine in 1997 and 2000, respectively. From2000 to 2003 he served as the networking architect forMagis Networks, designing high-speed wireless mediumaccess control. Since 2004 he has been an associate profes-sor in the Computer Science Department of UFF. Hisresearch interests include Internet architectures and proto-cols, wireless networks, multicast and multimedia services,and traffic control mechanisms.

OTTO CARLOS M. B. DUARTE received electronic engineer andM.Sc. degrees from UFRJ in 1976 and 1981, respectively,and a Dr.Ing. degree from ENST/Paris, France, in 1985.Since 1978 he has been a professor with UFRJ. From Jan-uary 1992 to June 1993 he was with MASI Laboratory, Uni-versité Paris 6. In 1995 he spent three months with theInternational Computer Science Institute (ICSI), Universityof California, Berkeley. In 1999, 2001, and 2006 he was aninvited professor at Université Paris 6. His major researchinterests are in multicast, QoS guarantees, security, andmobile communications.


Documents

On the impact of user mobility on peer-to-peer video streaming