P2P VIDEO BROADCAST BASED ON PER-PEER TRANSCODING AND ITSEVALUATION ON PLANETLAB

Naoki Shibata, Masaaki MoriDept. Info. Processing & Management

Shiga University1-1-1 Bamba, Hikone 522-8522, Japan

email: {shibata, mori}@biwako.shiga-u.ac.jp

Keiichi YasumotoGraduate School of Information ScienceNara Institute of Science and Technology

8916-5 Takayama, Ikoma 630-0192, Japanemail: yasumoto@is.naist.jp

ABSTRACTWe have previously proposed a P2P video broadcastmethod called MTcast for simultaneously delivering videoto user peers with different quality requirements. In thispaper, we design and implement a prototype system of MT-cast and report the results of its performance evaluation inthe real Internet environment. MTcast relies on each peerto transcode and forward video to other peers. We con-ducted experiments on 20 PlanetLab nodes, evaluated start-up delay and recovery time from peer leaving/failure, andconfirmed that MTcast achieves practical performance in areal environment.

KEY WORDSP2P, Video, Broadcast, Transcoding, Overlay Network

1 Introduction

Recently, many types of computing terminals ranging fromcell phone to HDTV are connected to the Internet, and con-sequently efficient video delivery method for many termi-nals with different computation powers, display sizes andavailable bandwidths is required. There are some studieson simultaneously delivering video to multiple users withdifferent quality requirements. In the multiversion tech-nique [1], multiple versions of a video with different bi-trates are stored at a server so that the most appropriatevideo can be delivered to each user within resource limi-tation. In the on-line transcoding method [2], the originalvideo is transcoded at a server or one of intermediate nodes(i.e. proxy) to videos with various quality, according to re-ceivers’ requests, and forwarded to the receivers. However,large computation power is required for transcoding by aserver or an intermediate node. In the layered multicastmethod [3, 4], video is encoded with layered coding tech-niques such as the ones in [5] so that each user can decodethe video by receiving arbitrary number of layers, althoughsplitting into many layers imposes computation overheadon user nodes.

Furthermore, there are many studies on video stream-ing in peer to peer networks such as OMNI[6] and theCoopNet[7]. In OMNI(Overlay Multicast Network Infras-tructure), each user node works as a service provider aswell as a service user, and a multicast tree is composed ofuser nodes so that the video delivery service is providedto all the user nodes through the tree. OMNI can adapt tothe change of the user node distribution and the networkconditions. In CoopNet, user nodes cache parts of streamdata, and deliver them through multiple diverse distribution

trees to the receiver nodes while the server load is high.OMNI and CoopNet, unfortunately, do not treat heteroge-neous quality requirements.

There are some approaches for heterogeneous qualityvideo delivery on P2P network. PAT [8] is a method to re-duce computation resources necessary for on-line transcod-ing in P2P network by making peers share the part of datagenerated during encoding and decoding of video. We havealso proposed MTcast (Multiple Transcode based videomulticast)[9] which achieves efficient and robust videobroadcast to multiple heterogeneous users by relying onuser peers to transcode and forward video. MTcast con-structs a tree whose root is the sender of the original videocontent as a variation of a perfect n-ary tree, where peerswith higher quality requirements are located near the rootof the tree.

In this paper, aiming to validate practicability and ef-fectiveness of MTcast in the real Internet environment, wedesign and implement MTcast system with a more effi-cient tree construction mechanism than the original MT-cast. In the new tree construction mechanism, parent-childrelationship between peers is decided based on bandwidthand topology measurement on physical path. We havealso designed and implemented a prototype system of MT-cast. With the prototype, we have conducted experimentson the PlanetLab[10], and confirmed that MTcast achievesreasonably short start-up latency, small channel switchingtime, and small recovery time from peer leaving/failure.

2 MTcast OverviewIn this section, we provide an overview of MTcast [9].

2.1 Target EnvironmentMTcast is a peer-to-peer based video broadcast method forheterogeneous peers whose available bandwidths, compu-tation powers, screen sizes, etc. are different. The targetenvironment of MTcast is shown in Table 1.

MTcast does not treat the VoD (Video on Demand)service. Instead, it provides a service of broadcasting avideo during the scheduled time to peers requiring thevideo, which is very similar to ordinary TV broadcasts. Af-ter a video broadcast starts, new users can join to receivethe video delivery from the scene currently on broadcast.

2.2 DefinitionsLet s denote a video server, and U = {u1, ..., uN} de-note a set of user nodes. We assume that for each ui,available upstream (i.e., node to network) bandwidth and

Table 1. Target Environment

Item ExplanationTypes of peers Desktop PC, laptop PC,

PDA, cell phone, etcPeer’s home network ADSL, CATV, FTTH,

WLAN, cellular network,etc connected to the Internet

Number of peers up to 100,000Contents for broad-cast

pre-recorded video

800kbps

700kbps 600kbps

500kbps400kbps 300kbps 200kbps

Figure 1. Video Broadcast through a Transcode Tree (n =2, k = 6)

downstream (i.e., network to node) bandwidth can be mea-sured. We denote them by ui.upper bw and ui.lower bw,respectively. Let ui.q denote ui’s video quality require-ment. We assume that ui.q is given by the bitrate of videocalculated by the required picture size and frame rate. Letui.ntrans(q) denote the maximum number of simultaneoustranscoding which can be executed by ui for videos withquality q. Let ui.nlink(q) denote the maximum numberof simultaneous forwarding of videos with quality q whichcan be performed by ui. ui.ntrans(q) and ui.nlink(q) arecalculated from computation power of ui, ui.upper bw andvideo quality.

MTcast constructs an overlay multicast tree where s isthe root node and user peers in U are intermediate (internal)or leaf nodes. Hereafter, this multicast tree is called thetranscode tree.

2.3 Structure of Transcode TreeInternal nodes in the transcode tree transmit a video streamto children nodes. In MTcast, each internal node basicallyhas n children nodes. The value of n is decided based onthe available resource of peers as explained in Sect. 2.4. Inorder to reduce the start-up delay for video playback andthe number of transcoding applied to video, the transcodetree is constructed as a modified complete n-ary tree wheredegree of the root node is k instead of n (k is a constantand explained later). The transcode tree is constructed sothat for each node ui and each of its children nodes uj ,ui.q ≥ uj .q holds. That is, from the root node to each leafnode, the nodes are ordered in decreasing order of qualityrequirements. In order to tolerate node leave/failures, ev-ery k nodes in U are bunched up into one group. We calleach group a layer, where k is a predetermined constant.In MTcast, peers in the same layer receive video with thesame quality. This quality is called the layer quality. Arepresentative peer is selected for each layer. Parent-childrelationship among all layers on the transcode tree is calledthe layer tree. An example of the transcode tree with n = 2and k = 6 is shown in Fig. 1, where, small circles and bigovals represent peers and layers, respectively.

1500

1300 700

1100 900 500 300

1400 1200 1000 800 600 400 200 100

1100 1100 900 500

leaf layerinternal layer

Figure 2. Layer Tree Construction

2.4 Construction of Transcode Tree

In MTcast, the transcode tree is calculated in a centralizedway by a peer uC ∈ U . We assume that the server s de-cides uC or behaves as uC . The tree construction algorithmconsists of the following three steps.Step 1: For each peer u ∈ U , the algorithm checks if ucan transcode one or more video streams in real time byinequality (1), and can transmit n + 1 video streams at thesame time by inequality (2).

u.ntrans(u.q) ≥ 1 (1)u.nlink(u.q) ≥ n + 1 (2)

If the above two inequalities hold for u, then u is put intoUI which is the set of internal peers, otherwise put into UL

which is the set of leaf peers. s is always put into UI . If|UI | < 1

n |U |, the whole network resource is not sufficientto satisfy the quality requirements of all peers. In such acase, we let |UL| − n−1

n |U | peers in UL with larger up-stream bandwidths to reduce their quality requirements sothat the inequalities (1) and (2) hold. Then, those peers aremoved to UI . By the above procedure, |UI | ≥ 1

n |U | alwaysholds.Step 2: Peers of UI are sorted in decreasing order of theirquality requirements and every bunch of k peers is packedto an internal layer, where k is the constant defined in 2.3.Here, we select the first and second peers of each layer asthe responsible peer and the sub-responsible peer of thelayer, respectively. The average value of quality require-ments in each layer is called the layer quality, and all peersin the layer adjust their quality requirements to the value.For the set of leaf nodes UL, elements are similarly packedto leaf layers.Step 3: The algorithm sorts internal layers in decreasingorder of the layer quality, and constructs the complete n-ary tree called the layer tree consisting of those internallayers where the layer quality of each layer does not ex-ceeds that of its parent layer. In MTcast, we use the depthfirst search order to assign internal layers to the layer treeas shown in Fig. 2. Next, the algorithm attaches each leaflayer L to the internal layer whose layer quality is closest toL. If the layer quality of L exceeds that of L’s parent layer,the layer quality of L is adjusted to that of L’s parent. Fi-nally, the transcode tree is obtained by assigning internalnodes and leaf nodes to the corresponding internal layersand leaf layers in decreasing order of their required qual-ity, respectively, and assigning parent-child relationshipsbetween peers according to the layer tree.How to decide transcode tree degree n and layer size k

In MTcast, the transcode tree is constructed as a mod-ified complete n-ary tree. So, as the value of n becomeslarge, the tree height (i.e., the number of transcoding) alsodecreases. Since the required upstream bandwidth of eachnode increases in proportion of n’s value, the value of nmust be carefully decided considering upstream bandwidthlimitation of each node. In order to avoid reducing the qual-ity requirements in Step 1, we should decide the value of nso that the number of peers satisfying the inequality (2) isno less than U

n .The value of k affects the tolerance of leave/failure of

peers. If f peers may leave from a layer at the same timebefore the transcode tree is reconstructed, the remainingk − f nodes in the layer must transmit video streams ton · k children nodes. So, the following inequalities musthold in order to recover from f simultaneous failures ineach layer.Thus, the appropriate value of k can be decidedfrom values of n and f .

(k − f)u.nlink(q) ≥ n · k (3)

(k − f)u.ntrans ≥ d k

u.nlink(q)en (4)

2.5 MTcast Protocols

Start-up Behavior Let t denote the time of video de-livery. Each user who wants to receive video stream sendsa video delivery request to the video server s before timet − δ. At time t − δ, s calculates the transcode tree withthe algorithm explained in Sect. 2.4. Here, δ is the timeto calculate the transcode tree and distribute the necessaryinformation to all nodes. Next, s distributes the followinginformation I or I ′ to all peers along T .

• I: information distributed to a responsible peer uR ofa layer LAll information of T including addresses of peersand their parent-child relationship, the structure of thelayer tree and the membership of peers, the addressesof responsible/sub-responsible peers, the layer qualityin each layer, and the next reconstruction time tr.

• I ′: information distributed to each peer p of layer Lother than L’s responsible peerThe addresses of L’s responsible peer, p’s childrenpeers, the responsible peer and sub-responsible peersof L’s parent layer, and the next reconstruction timetr. belongs,

(2) Protocols for peer joining and leaving As explainedbefore, each peer in an internal layer has an extra upstreambandwidth for forwarding one more video stream. A userpeer unew who has requested video delivery after time t canuse this extra bandwidth to receive a video stream instantly.Here, the fan-out of the forwarding peer uf which sends astream to unew is allowed to be n + 1 tentatively.

If one or more peers in a layer fail or suddenly leavefrom the transcode tree, all of their descendant nodes calledorphan peers will not be able to receive video streams. InMTcast, each orphan peer can find an alternative parentpeer by asking the responsible peer of the parent layer. Theresponsible peer received such a request ask one of peersin the layer to forward video stream to the orphan node by

(a) before failure (b) after recovery

Figure 3. Recovery from Node Failure

using its extra upstream bandwidths similarly to the case ofprocessing new delivery requests. An example is shown inFig. 3.(3) Reconstruction of Transcode Tree The transcodetree is periodically reconstructed to adjust tentatively in-creased degree (n + 1) to normal one (n). Peer uc recon-structs the transcode tree in the following steps.

First, uC collects quality requirements effective aftertime tr from all peers along the layer tree. Then, it calcu-lates the new transcode tree with the algorithm in Sect. 2.4,and distributes the information of the transcode tree to allpeers.

At time tr, all nodes stop receiving streams fromcurrent parent nodes and the nodes in the root layer ofthe new transcode tree starts to deliver video streams.Nodes in internal layers also forward video streams afterreceiving them. The video stream transmitted along thenew transcode tree arrives after a certain time lag due totranscode and link latency. During the time lag, each nodeplays back video from its buffer. For the next reconstruc-tion of the transcode tree, the buffer of each node must befilled with video data of the above time lag. This processis done by transmitting the video stream slightly faster thanits playback speed.

3 Implementation of MTcast System

In the original MTcast in [9], parent-child relationship ofpeers in the transcode tree is decided without considerationof property of overlay links. However, in the Internet, anoverlay link could be a long path with many hops in thephysical network. So, first, we have designed and imple-mented effective decision of parent-child relationship be-tween peers. Then, aiming to investigate usefulness of MT-cast in the real Internet environment, we have implementedMTcast system. We address details of the implementationin the following subsections.

3.1 Decision of parent-child relationship betweenpeers

As we already explained, the algorithm in Sect. 2.4 doesnot make a distinction between overlay links over differentASs (autonomous systems) and those within an AS. In thissubsection, we propose a technique to save bandwidths ofinter-AS links without spoiling the advantages of MTcast.

As our basic policy, we consider the physical networktopology to decide the parent-child relationship of peers inthe transcode tree.

Let C and P be the sets of peers which belong to alayer and its parent layer, respectively. For each pair of

peers between the child layer and the parent layer, the phys-ical path and the available bandwidth can be obtained withtools such as traceroute and Abing, respectively. Fro peersc ∈ C and p ∈ P , let bw(c, p) and L(c, p) denote theavailable bandwidth measured with such tools (called mea-sured available bandwidth, hereafter) and the set of phys-ical links between c and p except for links connected tonodes c and p, respectively.

Next, we estimate the available bandwidth of eachoverlay link (called estimated available bandwidth, here-after) by considering some of links are shared among mul-tiple overlay links. For each link l ∈ L(c, p), the estimatedavailable bandwidth dl and the sharing degree dl are de-fined as follows.

ml = Min{ bw(c, p) | l ∈ L(c, p), c ∈ C, p ∈ P}dl = | { c | l ∈ L(c, p), c ∈ C, p ∈ P} |

Based on the measured available bandwidth ml andthe sharing degree dl of each physical link, we decide theparent node of each child node as follows.

For each p ∈ P and c ∈ C, we investigate if c can re-ceive video stream with the required quality. If only a peer(say, p1) in P can transmit a video stream with the requiredquality to c, then the p1 is assigned as the parent node ofc. If some of peers in P can transmit the video stream toc, Maxp∈P Minl∈L(c,p)

ml

dlwhich represents the peer with

maximum available bandwidth per share, is assigned as c’sparent node.

We designed the prototype system with emphasis onthe following two points: (i) ease of implementation and(ii) reusablility of the finished software; when we changethe proposed method, the prototype system should be easilymodified to comply with the new specification, and a largepart of the software should be able to be reused in othersimilar projects. With these two requirements satisfied, wedevised the prototype system not to sacrifice performance.By adopting modular design, which is described below, wemade the process which runs on each node a generic pro-gram, and its functionality can be changed by changing thecode for central server process.

3.2 Modular designIn order to flexibly change formation of process on eachnode and facilitate performance evaluation under variousconfigurations, we designed the process on each node tobe a set of modules like buffer or transcoder. Process oneach node makes instance of these modules and connectsthem according to commands from the central server pro-cess. The central server process can also issue commandsfor particular modules on each node. We made these mech-anisms using Java language and RMI(Remote Method In-vocation). The modules include transcoder, video player,network data receiver, transmitter, buffer, user interface,configuration file reader, etc, and each of these modulescorresponds to one class. Each instance of the modulescorresponds to one thread so that the modules can be pro-grammed more easily than event-driven style code.

Each instance made by commands from the centralserver process is registered in a hash table on the node witha unique key. Methods of these instances can be invokedlater by referring this hash table. The prototype systemshould make some action according to status changes on

modules like lost connection or the amount of buffered dataexceeding a threshold. In our design, the central processis informed of these changes through a queue for statuschange message arranged in the central process. In caseof status change, the corresponding module puts a messageinto the queue, and the central process takes an appropriateaction according to the incoming message.

3.3 Devices to facilitate video stream handlingAlthough a mechanism similar to InputStream and Output-Stream classes in the standard Java library can be used toexchange video streams between modules, it would be trou-blesome to realize a procedure like restarting transcoderwith different parameters during processing a successivestream. In the prototype system design, we made an orig-inal class whereby each end of frame data is explicitly de-clared by transmitter, and receiver reads data until end offrame data as usual, but after that, the read method returns-2 like when it reaches EOF, and then the receiver contin-ues reading data of the next frame. With this specification,each end of frame data can be easily processed without de-stroying and remaking module instances.

Stream processing can be realized using JMF(JavaMedia Framework), but it is known that there will be a largeprocessing delay due to buffers placed on each processingmodule. In the prototype system, we tried to minimize pro-cessing delay by reducing buffering on each module. Inthe system, while each module basically corresponds to athread, we made the write method to block until the cor-responding reader thread reads all of written data by thatcall. By this design, processing delay is reduced sincewhen a module invokes write method, control is immedi-ately passed to the reader thread, and thus there is no pro-cessing delay due to thread switching interval of operatingsystem.

3.4 Devices to facilitate evaluation on many PlanetLabnodes

In order to facilitate evaluation using several tens of Plan-etLab nodes, we devised the following manner. Conditionsof PlanetLab nodes momently change, and good nodes fre-quently becomes unavailable after short period of time. Inorder to cope with this situation, we made a set of scriptswhich checks currently installed files on each node, and up-date them if necessary. The scripts consist of ones run onthe operator’s host, and ones run on PlanetLab nodes. Theformer scripts copies necessary scripts and files on Planet-Lab nodes using scp command, and execute them. Thisoperation is executed in parallel. The latter scripts checkthe version of installed files, and if necessary, downloadand install them using wget command. We used thesescripts, and confirmed that it takes less than 30 minutesto install java run time environment to 30 PlanetLab nodes.We also confirmed that installing java class files for the pro-totype system on these nodes takes about 1 minute.

4 Performance Evaluation

In order to show practicality of MTcast, we need to val-idate (1) overhead of real-time transcoding by user peersand (2) network and processing overhead for constructing atranscode tree, (3) recovery time after peer leaving/failure.

For the usefulness of MTcast, we also need to validate (4)user satisfaction (i.e., whether each user can receive andplay back video at his/her requested quality), (5) efficiencyof the transcode tree (in terms of overlay link lengths), and(6) start-up delay (i.e., the time delay for video to be dis-played after its request).

In [9], we already showed that the validity of theabove (1), (2) and (4), and confirmed that desktop PCs andlap-top PCs have enough power for real-time transcodingof a video stream (for (1)), an ordinary PC can calculatethe transcode tree with 100,000 peers in 1.5 second and thetree size is within 300Kbyte (for (2)), and MTcast achieveshigher user satisfaction than layered multicast using 10 lay-ers through computer simulation (for (4)).

In Sect. 4.1, we present the detailed experimental re-sults of applying our prototype system to show the validityof the above (3), (5), and (6).

4.1 Evaluation on PlanetLab nodes

In order to evaluate the performance of proposed methodin the real environment, we operated our prototype systemon PlanetLab nodes. In this section, we describe the resultof measurement for time required to join, delay introducedby successive forwarding and transcoding, the behavior incase of abrupt departure of node, and effectiveness of band-width saving method for backbone links.

Configuration

We used video with pixel size of 180 × 120 and framerate of 15fps, without audio. We used motion JPEG as theCODEC of video.

We used TCP to transmit video data between nodes.In order to evaluate scalability, we constructed thetranscode tree as a cascade of layers with two nodes, in-stead of the modified n-ary tree. In the experiments,we used several tens of PlanetLab nodes including nodesshowed in Table 2. We also used katsuo.naist.jp andwakame.naist.jp, which do not belong to PlanetLab. Weexecuted the originating video server at katsuo.naist.jp, andone user node process on each other nodes. Due to constanthigh processing load on PlanetLab nodes, it was difficult toallocate processing power required for transcoding, and sowe did not performed transcoding on each node. Instead,we make each node just buffer data for one frame, andtransmit it unprocessed. We believe that when our methodis used for practical use, the processing power for transcod-ing is surely available.

Table 2. Nodes used in experiments

katsuo.naist.jp pl1-higashi.ics.es.osaka-u.ac.jpwakame.naist.jp planetlab3.netmedia.gist.ac.krplanet0.jaist.ac.jp planetlab1.netmedia.gist.ac.krplanetlab-01.naist.jp planetlab2.iii.u-tokyo.ac.jpplanetlab-02.naist.jp planetlab1.iii.u-tokyo.ac.jpplanetlab-03.naist.jp planetlab5.ie.cuhk.edu.hkplanetlab-04.naist.jp planetlab4.ie.cuhk.edu.hkplanetlab1.tmit.bme.hu planetlab-02.ece.uprm.eduplanetlab2.tmit.bme.hu planetlab-01.ece.uprm.edu

planetlab02.cnds.unibe.chplanetlab01.cnds.unibe.ch

Table 3. Time required for starting up

# of nodes establishing connection receiving data4 10,871ms 19,040ms8 11,681ms 16,993ms12 15,307ms 15,307ms16 11,317ms 18,781ms20 12,144ms 17,562ms

Table 4. Delay introduced by forwarding

# of nodes delay14 7,002 ms16 8,603 ms20 20,573 ms23 10,024 ms27 9,435 ms

Time required for start-up

Table 3 shows the times required for starting up. Thecolumns for establishing connection and receiving data in-dicate the required times since start of the system untilthe last node establishes connection and until the last nodereceives first byte of data, respectively. Please note thatthese times include Java JIT compiler to compile byte code.Since all nodes establish connections in parallel, the ob-tained time is the maximum time required for nodes to es-tablish connection. Since leaf nodes have to receive datavia their descendant nodes, the time to receive data is con-sidered to be proportional to the height of tree. But actually,increase of time is not observed as the height of tree grows.This is because the time required to establish connection isdominant. Anyway, these times are less than 20 seconds,and thus these values are practical.

Delay introduced by successive forwarding andtranscoding

Table 4 shows the time since the first node receives firstbyte of data until the last node receives first byte of data.The result is similar to the result of start-up delay measure-ment. The times are less than 21 seconds, and thus thesevalues are practical.

Behavior in case of abrupt node departure

Table 5 shows the time to reestablish connection after nodedeparture. The time to reconnect and restarting receivingdata are the time since the departure node sends depar-ture request until its child node reestablishes connection toa new parent node, and the child node receives first byteof data from the new parent node, respectively. We usedthe cascading transcode tree topology which is same as thelast measurement, and made the node indicated in the ta-ble leave the system. The measured times are less than twoseconds, and users see video uninterruptedly in this periodsince video stream data is buffered in each node. Thus, theresults are practical.

Table 5. Behavior in case of node departure

departure node new parent node time to time toreconnect restart

planetlab1.netmedia.gist.ac.kr thu1.6planetlab.edu.cn 1,471ms 1,805msplanetlab4.ie.cuhk.edu.hk planetlab1.netmedia.gist.ac.kr 288ms 411msplanetlab-01.ece.uprm.edu planetlab5.ie.cuhk.edu.hk 1,114ms 1,657msplanetlab1.tmit.bme.hu planetlab-02.ece.uprm.edu 1,383ms 1,626msplanetlab01.cnds.unibe.ch planetlab1.tmit.bme.hu 1,541ms 1,841msplanetlab2.iii.u-tokyo.ac.jp planet0.jaist.ac.jp 61ms 1,004ms

Effectiveness of bandwidth saving method for backbonelinks

In order to evaluate the effectiveness of bandwidth savingmethod for backbone links described in 3.1, we comparedthe number of total hops in the transcode tree when the sys-tem chooses parent nodes for each node at random, usingthe method in 3.1, and using a method to choose nearesthop parent. In this experiment, we set the number of nodesper layer to be 4, and used cascaded transcode tree. Wemake the system obtain route between nodes and availablebandwidth between nodes using traceroute and Abing[11],respectively. Some routers between nodes did not respondto ICMP Echo message, and these routers are treated asdifferent routers for each route between nodes. Routesand available bandwidth are obtained before constructingtranscode tree, and these are performed in parallel for eachroute, and this took about 30 seconds. Table 6 shows thetotal hop counts in the transcode tree measured three times.Note that even if we used the method in 3.1, the resultingtranscode tree differs each time since the results of mea-surement for available bandwidth differs each time. Theresults indicate that using the method in 3.1 leads to 16%fewer hop count, and choosing nearest hop parent leads to41% fewer hop count.

Table 6. Effectiveness of backbone bandwidth saving

method # of hopsrandom 343, 361, 335

method in 3.1 314, 280, 277minimum hop count 204, 204, 204

5 Conclusion

In this paper, we have implemented the algorithm and pro-tocols of MTcast proposed in [9] and showed the practical-ity and performance of MTcast through experiments madeon PlanetLab.

In the future work, we will extend the algorithm ofMTcast to treat multi-dimensional quality requests includ-ing picture size, frame rate, and bit rate, and transcode eachquality factor independently of others.

References

[1] G. Conklin, G. Greenbaum, K. Lillevold, and A.Lippman: “Video Coding for Streaming Media De-livery on the Internet,” IEEE Trans. on Circuits andSystems for Video Technology, Vol. 11, No. 3, 2001.

[2] S. Jacobs and A. Eleftheriadis: “Streaming Videousing Dynamic Rate Shaping and TCP Flow Con-trol,” Visual Communication and Image Representa-tion Journal, 1998. (invited paper).

[3] J. Liu, B. Li, and Y.-Q. Zhang: “An End-to-EndAdaptation Protocol for Layered Video Multicast Us-ing Optimal Rate Allocation,” IEEE Trans. on Multi-media, Vol. 6, No. 1, 2004.

[4] B. Vickers, C. Albuquerque and T. Suda : “Source-Adaptive Multilayered Multicast Algorithms forReal-Time Video Distribution,” IEEE/ACM Trans. onNetworking, Vol.8, No.6, pp.720-733, 2000.

[5] H. Radha, M. Shaar, Y. Chen: “The MPEG-4 Fine-Grained-Scalable video coding method for multime-dia streaming over IP,” IEEE Trans. on Multimedia,Vol. 3, No. 1, 2001.

[6] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattachar-jee and S. Khuller : “Construction of an EfficientOverlay Multicast Infrastructure for Real-time Ap-plications,” Proc. of IEEE Inforcom 2003, pp.1521-1531, 2003.

[7] V. Padmanabhan, H. Wang, P. Chow and K. Sripanid-kulchai : “Distributiong streaming media content us-ing cooperative networking,” Proc. of the 12th Int’lWorkshop on Network and Operating Systems Sup-port for Digital Audio and Video (NOSSDAV 2002),pp.177-186, 2002.

[8] D. Liu, E. Setton, B. Shen and S. Chen : “PAT: Peer-Assisted Transcoding for Overlay Streaming to Het-erogeneous Devices,” Proc. of 17th Int’l Workshop onNetwork and Operating Systems Support for DigitalAudio and Video (NOSSDAV 2007), pp.51-53, 2007.

[9] T. Sun, M. Tamai, K. Yasumoto, N. Shibata, M.Ito and M. Mori : “MTcast : Robust and EfficientP2P-Based Video Delivery for Heterogeneous Users,”Proc. of the 9th Int’l. Conf. on Principles of Dis-tributed Systems (OPODIS 2005), pp.176-190, 2005.

[10] PlanetLab: “An open platform for developing, de-ploying, and accessing planetary-scale services,”https://www.planet-lab.org/.

[11] J.Navratil and R. L. Cottrell : “ABwE: A PracticalApproach to Available Bandwidth Estimation,”http://www-iepm.slac.stanford.edu/tools/abing/