SlideShare una empresa de Scribd logo
1 de 4
Descargar para leer sin conexión
CONTENT-AWARE P2P VIDEO STREAMING WITH LOW LATENCY

                        Pierpaolo Baccichet∗ , Jeonghun Noh† , Eric Setton‡ and Bernd Girod†
              ∗
                  Max Planck Center for Visual Computing & Communication, Stanford, CA 94305
                     †
                       Information Systems Laboratory, Stanford University, Stanford, CA 94305
                  ‡
                    Streaming Media Systems Group - Hewlett-Packard Labs, Palo Alto, CA 94306
                              {bacci,jhnoh,bgirod}@stanford.edu, eric.setton@hp.com


                            ABSTRACT                                     with the number of descriptions received. Alas, MDC introduces
                                                                         substantial redundancy relative to single-description coding. This
This paper describes the Stanford P2P Multicast (SPPM) streaming
                                                                         redundancy unnecessarily degrades the rate-distortion performance,
system that employs an overlay architecture specifically designed
                                                                         if no packet losses or node failures occur.
for low delay video applications. In order to provide interactivity to
the user, this system has to keep the end-to-end delay as small as            In this paper, we present a tree-based solution that does not re-
possible while guaranteeing a high video quality. A set of compli-       quire MDC but exploits local retransmission to mitigate packet loss.
mentary multicast trees is maintained to efficiently relay video traf-    By maintaining multiple distribution trees, it is possible to direct a
fic and a Congestion-Distortion Optimized (CoDiO) scheduler pri-          retransmission request for a missing packet from a particular tree to
oritizes more important video packets. Local retransmission is em-       a parent in another distribution tree. Our approach integrates recent
ployed to mitigate packet loss. Real-time experiments performed on       work done on Congestion-Distortion Optimized packet scheduling
the Planet-Lab show the effectiveness of the system and the benefits      [6] to prioritize the delivery of video data according to the percep-
of a content-aware scheduler in case of congestion or node failures.     tual importance. An overview of the protocol is provided in Sec.
                                                                         2 while the details of system architecture and implementation are
                                                                         reported in Sec. 3. Simulation results obtained on Planet-Lab are
                      1. INTRODUCTION                                    reported in Sec. 4.
In recent years, video streaming over the Internet has become more
and more popular due to the increasing availability of bandwidth and
recent advances in video coding technologies. In several application                2. OVERLAY MULTICAST PROTOCOL
scenarios, such as IP-TV, the same video content has to be transmit-
ted to a large population of users. Content Delivery Networks (such      The Stanford P2P Multicast (SPPM) protocol organizes peer nodes
as Akamai [1]) are often used to support large numbers of users but      in an overlay that consists of a set of multicast trees. The source of
they require the deployment of special infrastructure. As an alterna-    the stream is the root of each distribution path and multiplexes video
tive, Peer-to-Peer (P2P) overlay networks have been considered for       packets on different trees to ensure load balancing. Fig. 1 shows a
delivery of multimedia. The idea is that users who are interested in     simple topology with eight peers and two distribution trees as an ex-
a video stream can act as relay points and forward the data to other     ample of the overlay created by SPPM. In the following, we describe
users, thus allowing the system to scale with the number of nodes        how our solution maintains the overlay network and guarantees error
involved in the communication. P2P systems are widely used for           resilience.
video file sharing. For live multicasting, however, the problem is
much more challenging, as the overlay network must guarantee high
reliability of the connections and a constant flow of data, as well as
low startup latencies.                                                              S
     Several different architectures have been proposed in the liter-                                           P1                   P5
ature that can be grouped in two different categories. Mesh-based
approaches (such as GridMedia [2]) aim to construct an overlay
mesh whose connections are maintained through “gossiping”. Even
                                                                                                        P2
though these solutions provide good error resilience and network uti-
lization performance, they are usually characterized by high startup
delays. This is mostly due to the Push-Pull approach followed in                 P4                                             P6
the dissemination of the video data that requires the receivers to co-                          P3
ordinate the download of different portions of information. On the
other hand, Tree-based approaches simply Push video packets along
routes that are determined by constructing one [3] or many [4, 5]                                             P7
multicast trees rooted at the media source. These solutions may                                                        Tree 1
lead to low latencies but they often assume the source signal to be                              P8                    Tree 2
encoded using Multiple Description Coding (MDC). With this ap-
proach independent descriptions can be sent over different network
paths. The quality of the reconstruction at the decoder increases          Fig. 1. An example overlay that consists of two multicast trees.
JOIN                   PROBE                  ATTACH              2.1.3. Loop prevention
          Source           Candidate Parents         Selected Parent       During the reconnection process, a node may attach to one of its
                                                                           descendants. This loop would eventually starve the whole subtree.
                                                                           To prevent this problem, each peer keeps the list of its ancestors. In
                                                                           our implementation, a specific ANCESTOR UPDATE packet allows
                                                                           updating of this list whenever a change in the topology occurs. Peers
                                                                           can easily reject attachment requests issued by an ancestor. This
                                                                           loop avoidance mechanism does not require global knowledge of the
         New Peer                                                          topology but only of a small subset of its nodes. Additional memory
                                                                           and processing power requirements are negligible.
Fig. 2. SPPM implements a six-way handshake process to join peers
to the session. Each new peer 1) contacts the source, 2) probes a set      2.2. Content-aware scheduling
of candidate parents and 3) attaches to a selected parent.
                                                                           Relaying traffic over the uplink of the peers may lead to conges-
                                                                           tion on the multi-hop path separating the source from any particular
                                                                           peer. Because the rate of a video stream often varies, a peer may
2.1. Topology construction and management
                                                                           sometimes lack the resources to forward all the data expected by its
A new node joining a multicast first contacts the source to obtain a        descendants. When a peer has to drop some packets to ensure timely
set of nodes that are already connected to the system. These nodes         delivery of the more significant portion of the streams, prioritized
are inquired for available resources to determine whether they can         scheduling can help maintain video quality. In related work [7], we
act as parents in the distribution trees. Since the source of the stream   presented a Congestion-Distortion optimized CoDiO packet sched-
is continuously online, it can easily manage a database of these con-      uler. This prioritization algorithm bases its decisions on the “im-
nected peers. The join process consists of a “six-way” handshake as        portance” D(n) of each enqueued packet. The metric reflects how
described in the following and shown in Fig. 2.                            decoding of a particular packet reduces distortion and it captures the
                                                                           dependencies among different packets as shown in Fig 3. Hence, the
    • JOIN. The new peer contacts the source of the video stream           scheduler adapts its decisions to the video content by relaying more
      that replies with some setup information, such as the number         important packets first.
      of multicast trees and the video bit rate. Also, it sends a set
      of currently connected peers that can be polled as candidate
      parents.                                                                    I1 B2 B3 P4 B5 B6 P7 B8 B9 P10 B11 B12 P13 B14 B15 I16 …
    • PROBE. For each tree, the new peer probes each candidate             D(n)   15   1   1   14   1   1   11   1   1   8   1   1   5   1   1   17

      parent to obtain their current state and determine the best par-
      ent to which to connect. Each candidate parent replies provid-       Fig. 3. Content-aware packet scheduling can be implemented by
      ing the available bandwidth and its height in the distribution       looking at the interdependencies among video packets.
      tree.
    • ATTACH. For each tree, one out of the set of candidate par-
      ents is selected and an actual connection is established. The                            3. SYSTEM ARCHITECTURE
      parent is selected by minimizing the height of the distribution
      tree. Also, different parents are chosen as often as possible to     We have implemented a real-time prototype of the SPPM protocol
      exploit path diversity.                                              that uses the state-of-the-art H.264/AVC [8] to efficiently encode the
                                                                           source signal. Video frames are fragmented at the source to a maxi-
                                                                           mum of 1300 bytes to reflect the MTU of a typical ethernet network
2.1.1. Monitoring the connection                                           thus avoiding packet fragmentation in lower layers of the protocol
                                                                           stack. We use UDP as a transport protocol to avoid the overhead in-
Once the connection is established, each peer periodically sends           volved in the usage of TCP. Two different UDP ports are used for the
HELLO REQ messages to the parents in the distribution trees which          control and video traffic respectively. A list of the different packet
in turn reply with a HELLO REP message. Whenever a host leaves, it         types is reported in Table 1.
stops forwarding video packets and it is unresponsive to HELLO REQ              The software architecture of a SPPM peer is shown in Fig. 4.
messages. Thus, peers can detect a parent disconnection and trigger        Several threads provide the services needed and the “queue man-
the rejoin procedure for the affected tree. Similarly, parent peers        ager” and the “routing table” monitors are used for synchronization.
record the arrival times of the HELLO REQ messages received by             The basic modules are reported in the following.
each child, in order to detect children disconnections and release re-
sources.                                                                       • Control Agent is responsible for maintaining the connection
                                                                                 to the system. It accepts connection requests from the chil-
                                                                                 dren and updates the routing tables accordingly. It periodi-
2.1.2. Local retransmission                                                      cally monitors the status of parents by sending HELLO REQ
Quality degradation due to packet loss and temporary disconnec-                  messages and, in case of a disconnection, it triggers the re-
tion can be mitigated using retransmission. Note that path diversity             connection process.
allows retransmission requests to be limited to local parents, thus            • Video Agent receives the incoming video packets, retrieves
avoiding feedback implosion at the source of the stream. See [7] for             from the routing table the list of children to which the packet
further details.                                                                 has to be relayed and then stores it into the video queue.
Incoming           Video                  Queue Manager                                        Decoder
                  Video traffic       Agent                                                    Playout
                                                                                               Buffer
                                                                 Video Queue

                                  Routing Table


                                                                                                Relay         Outgoing
                                                                 Control Queue                                 traffic
                                                                                                Agent
                      Control        Control
                      packets         Agent

Fig. 4. The SPPM software architecture. Video and control packets received from the network are stored into a common buffer within a
Queue Manager that performs prioritization and garbage collection. Packets are then relayed to children or displayed at regular intervals by
appropriate playout and relay agents.


    • Routing table stores the list of children for each tree.                             4. EXPERIMENTAL RESULTS
    • Queue Manager implements a common buffer to store pack-
                                                                          We tested our real-time SPPM prototype on Planet-Lab [9] and per-
      ets that are to be relayed or displayed. A garbage collector
                                                                          formed experiments using 100 nodes. As a test video, we concate-
      periodically discards packets that are expired, i.e. that have
                                                                          nate several well-known sequences at CIF resolution at 30 frames
      passed their playout deadline.
                                                                          per second. We encoded the video using H.264/AVC at 400kbps ob-
    • Relay Agent periodically extracts from the queue the next           taining an average video quality of 34.5 dB of PSNR. In order to
      packet to be sent and forwards it to the appropriate child.         allow users to join at different times, we sent one intra coded frame
    • Playout Buffer retrieves packets that are to be displayed from      every half second. The group of pictures (GOP) was similar to the
      the video queue and passes them to the video decoder.               one shown in Fig. 3. The playout deadline was set to 5 seconds and
                                                                          we used 8 different multicast trees.
    The source of the video stream implements two additional mod-              Each session consisted of 30 minutes of video streaming. The
ules that are described in the following.                                 peers were scheduled to randomly connect within the first minute
                                                                          and to stay connected to the system for the whole session. Note
    • Video Packetizer reads the H.264/AVC input video, either            that each node on Planet-Lab shares both link and processing power
      from a file or from a socket, and performs packet fragmenta-         with several other users. In this environment, conditions may vary
      tion whenever it is necessary. In our implementation, we set        quickly possibly causing temporary congestion to occur on the links.
      the maximum size of a video packet equal to 1300 bytes to
      reflect the MTU of an Ethernet.
                                                                          4.1. Video performance
    • Connected peers’database maintains an approximate list of
      connected peers. Each entry in the list is refreshed with peri-     We show the results of three different experiments to demonstrate the
      odical information received from the peers via PEER UPDATE          effectiveness of the retransmission and prioritization scheme of our
      packets. If the source fails to receive such packets from a reg-    solution. We observed that several nodes fail to provide good video
      istered peer for a certain amount of time, it considers the peer    quality to the user when retransmission and prioritization are not
      as disconnected from the system and frees the entry in the          used. In this case, the PSNR across all the peer is equal to 30.1 dB. A
      table.                                                              significant improvement is observed after introducing retransmission
                                                                          with an average quality of 31.8 dB while the best performance of
3.1. NAT Support                                                          33.2 dB was obtained by combining retransmission with the content-
                                                                          aware packet scheduler described in Sec. 2.2. Fig. 5 shows the
A vast majority of residential users access the Internet via some kind    average video quality observed at selected peers.
of Network Address Translator (NAT) device that usually filters un-            Whenever a peer fails to receive data for a certain amount of
solicited incoming traffic directed to nodes of the local network. A       time, the video decoder performs error concealment by displaying
NAT will forward incoming traffic from a specific IP address only           previously received frames in lieu of the lost ones. Long frame
if a packet has been sent to that IP address before. In order to sup-     freezes can be considered an indication of a failure in the connec-
port devices behind NATs, our “six-way” handshake procedure has           tion to the system and must be limited. We observed a significant
to be slightly modified because the PROBE REQ messages would be            decrease in the number of frame freezes by using retransmission and
normally filtered as unsolicited traffic. We assume the source of the       prioritization, as reported in Table 2.
stream to be running on a computer with a static IP address. When
the source receives a join request, it can detect the public address of   4.2. Startup delay
the new peer and send this information to the set of potential can-
didate parents. The parents then transmit a dummy packet to the           The main design goal of our solution is to provide high video quality
control port of the new peer. This creates a binding on the NAT           with very low latency. To validate the effectiveness of the implemen-
device that will enable the forwarding of subsequent PROBE REQ            tation, we recorded the minimum startup delay necessary to receive
messages.                                                                 the first decodable picture at each peer. We observed an average
Type                      Size      Description
               JOIN REQ                    40      Join request is sent by the new peer to the source.
               JOIN REP                  200+      Join reply contains setup information and list of candidate parents.
               PROBE REQ                   32      Probe request is sent to every candidate parent to collect information about the current status.
               PROBE REP                   40      Probe reply contains information regarding the current status of the candidate parent.
               ATTACH REQ                  40      Attach request is used to establish the actual connection with the selected parent.
               ATTACH REP                  40      Attach reply confirms the established connection.
               HELLO REQ                   36      Hello request sent to periodically monitor the state of the parent.
               HELLO REP                   40      Hello reply is used to disseminate information about the end-to-end delay from the source.
               PEER UPDATE                 60      Status information periodically sent to the source to update the list of connected peers.
               ANCESTOR UPDATE            60+      Propagates the list of ancestors on each tree to avoid creation of loops.

                  Table 1. Summary of the packet types used by SPPM. Sizes are expressed in bytes and include the overhead due to UDP/IP.


             35
                                                                                                           5. CONCLUSIONS
                                                                  No retr.
             34                                                   Retr.             In this paper, we reported the design and implementation of the Stan-
                                                                  Retr. + Prio.     ford Peer-to-Peer Multicast - SPPM protocol that allows the delivery
                                         No retr.  Retr.      Retr. + Prio.
             33
             umontreal.ca                    30,40      32,05      32,87
                                                                                    of a video stream from a source to a population of users with very
 PSNR [dB]




             osaka-u.ac.jp                   29,86      31,56      32,75            low delay. Experimental results obtained on the Planet-Lab confirm
             rochester.edu                   31,30      32,75      32,74            the effectiveness of the protocol. Startup delay was measured on the
             32
             duke.edu                        30,20      31,50      33,98            order of one second (on average). Video quality was improved by
             sunysb.edu                      31,03      32,05      33,89            2dB on average by introducing a Congestion-Distortion Optimized
             uni-hannover.de
             31                              30,23      31,74      33,85
             stanford.edu                    29,30      31,45      33,98
                                                                                    packet scheduler and local retransmission.
             utoronto.ca                     31,95      31,98      32,76
             30
             washington.edu                  29,80      31,89      33,65
             cornell.edu                     30,19      32,15      32,90                                    6. REFERENCES
             pbs.org                         29,50      31,98      33,04
             29
             utexas.edu                      28,90      30,66      32,84
                                                                                    [1] “Akamai,” http://www.akamai.com.
             stir.ac.uk                      30,72      31,50      32,89
              un uny du

                       no du




                                    k
                                   u
                                  du



                       st d u
                       ex rg
                      es .jp
                        a- ca




               wa oro du
                        fo de
                       du du




                        g t ca




                                 .u
                    co . e d



                    u t s.o
                   ch a c



                               .e
                                 .




                                 .
                    a n .e



                               .e




                              l.e



                               .e
                                .
                             r.e




                              ac




                                                                                    [2] M. Zhang, J. Luo, L. Zhao, and S. Yang, “A peer-to-peer
                              al




                  sh n t o




                                             30,26      31,79      33,24
                  st ver
                           ke

                           sb




                           as
                           on
                           rd
             re

                           u.




                           el
                         pb



                          ir.
                          te




                        rn
           t
        on




                                                                                        network for live media streaming using a push-pull approach,”
                     an
               ak




                     in
                    ut
um




                    s
             os




                i-h
                    ro




                                                                                        Proc. of the 13th annual ACM international conference on Mul-
                                                                                        timedia, pp. 287–290, 2005.
Fig. 5. Average PSNR measured over 30 minutes of video on Planet-                   [3] Y. Chu, S. Gao, and H. Zhang, “A case for end system multi-
Lab for 13 sample nodes.                                                                cast,” Proc. ACM Sigmetrics, Santa Clara USA, June 2000.
                                                                                    [4] M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi, A. Row-
             Scheme                       0.5 to      1 to     More than                stron, and A. Singh, “SplitStream: High-bandwidth content dis-
                                          1 sec.     2 sec.     2 sec.                  tribution in a cooperative environment,” Proc. IPTPS’03, Berke-
             No retransmission            4262       1784        457                    ley, CA, Feb. 2003.
             Retransmission                742        283        127
                                                                                    [5] V. N. Padmanabhan, H. J. Wang, P. A. Chou, and K. Sripanid-
             Retrans. & Prioritization     364        143         43
                                                                                        kulchai, “Distributing Streaming Media Content Using Coop-
                                                                                        erative Networking,” Proc. ACM NOSSDAV, Miami Beach, FL,
Table 2. Number and duration of the observed frame freezes for the
                                                                                        May 2002.
three considered scenarios over 100 different peers.
                                                                                    [6] E. Setton, “Congestion-Aware Video Streaming over Peer-to-
                                                                                        Peer Networks,” Ph.D. Thesis, Stanford University.
startup delay of one second. All the peers connected to the system                  [7] E. Setton, J. Noh, and B. Girod, “Rate-Distortion Optimized
within two seconds from the join request.                                               Video Peer-to-Peer Multicast Streaming,” Workshop on Ad-
                                                                                        vances in Peer-to-Peer Multimedia Streaming at ACM Multime-
                                                                                        dia, Singapore, pp. 39–48, Nov. 2005.
4.3. Protocol overhead
                                                                                    [8] ITU-T and ISO/IEC JTC 1, Advanced Video Coding for Generic
The SPPM protocol introduces a very small control overhead to                           Audiovisual services, ITU-T Recommendation H.264 - ISO/IEC
manage the overlay. We recorded the size and number of packets ex-                      14496-10(AVC), 2003.
changed, including the overhead due to UDP/IP encapsulation. We                     [9] “Planet-Lab,” http://www.planet-lab.org.
observed control packets are no more than 4% of the total traffic. If
we consider the additional header information introduced for each
video packet, i.e., sequence numbers and timestamps, the overhead
of the protocol is smaller than 8% of the total traffic.

Más contenido relacionado

La actualidad más candente

Transition to ipv6 cgv6-edited
Transition to ipv6  cgv6-editedTransition to ipv6  cgv6-edited
Transition to ipv6 cgv6-editedFred Bovy
 
Communications systems
Communications systemsCommunications systems
Communications systemsMohd Arif
 
communication system l2
communication system l2communication system l2
communication system l2MR Z
 
DDS over Low Bandwidth Data Links - Connext Conf London October 2014
DDS over Low Bandwidth Data Links - Connext Conf London October 2014DDS over Low Bandwidth Data Links - Connext Conf London October 2014
DDS over Low Bandwidth Data Links - Connext Conf London October 2014Jaime Martin Losa
 
Data Networking Concepts
Data Networking ConceptsData Networking Concepts
Data Networking ConceptsPeter R. Egli
 
Networking lecture 4 Data Link Layer by Mamun sir
Networking lecture 4 Data Link Layer by Mamun sirNetworking lecture 4 Data Link Layer by Mamun sir
Networking lecture 4 Data Link Layer by Mamun sirsharifbdp
 
RINA Introduction, part II
RINA Introduction, part IIRINA Introduction, part II
RINA Introduction, part IIICT PRISTINE
 
Communications
CommunicationsCommunications
Communicationssimosk
 
Building Linux IPv6 DNS Server (Draft Copy)
Building Linux IPv6 DNS Server (Draft Copy)Building Linux IPv6 DNS Server (Draft Copy)
Building Linux IPv6 DNS Server (Draft Copy)Hari
 
Investigation of dhcp packets using wireshark
Investigation of dhcp packets using wiresharkInvestigation of dhcp packets using wireshark
Investigation of dhcp packets using wiresharkjpratt59
 
protocol architecture
 protocol architecture protocol architecture
protocol architectureSrinivasa Rao
 

La actualidad más candente (20)

Osi 7 layer
Osi 7 layerOsi 7 layer
Osi 7 layer
 
3rd edition chapter1
3rd edition chapter13rd edition chapter1
3rd edition chapter1
 
Transition to ipv6 cgv6-edited
Transition to ipv6  cgv6-editedTransition to ipv6  cgv6-edited
Transition to ipv6 cgv6-edited
 
2 applications.key
2 applications.key2 applications.key
2 applications.key
 
Communications systems
Communications systemsCommunications systems
Communications systems
 
App layer
App layerApp layer
App layer
 
communication system l2
communication system l2communication system l2
communication system l2
 
Profile_Prateek
Profile_PrateekProfile_Prateek
Profile_Prateek
 
DDS over Low Bandwidth Data Links - Connext Conf London October 2014
DDS over Low Bandwidth Data Links - Connext Conf London October 2014DDS over Low Bandwidth Data Links - Connext Conf London October 2014
DDS over Low Bandwidth Data Links - Connext Conf London October 2014
 
RASHMI VT REPORT
RASHMI VT REPORTRASHMI VT REPORT
RASHMI VT REPORT
 
Ecommerce Chap 11
Ecommerce Chap 11Ecommerce Chap 11
Ecommerce Chap 11
 
Data Networking Concepts
Data Networking ConceptsData Networking Concepts
Data Networking Concepts
 
Networking lecture 4 Data Link Layer by Mamun sir
Networking lecture 4 Data Link Layer by Mamun sirNetworking lecture 4 Data Link Layer by Mamun sir
Networking lecture 4 Data Link Layer by Mamun sir
 
RINA Introduction, part II
RINA Introduction, part IIRINA Introduction, part II
RINA Introduction, part II
 
Communications
CommunicationsCommunications
Communications
 
Ch05
Ch05Ch05
Ch05
 
Building Linux IPv6 DNS Server (Draft Copy)
Building Linux IPv6 DNS Server (Draft Copy)Building Linux IPv6 DNS Server (Draft Copy)
Building Linux IPv6 DNS Server (Draft Copy)
 
Investigation of dhcp packets using wireshark
Investigation of dhcp packets using wiresharkInvestigation of dhcp packets using wireshark
Investigation of dhcp packets using wireshark
 
Introduction P2p
Introduction P2pIntroduction P2p
Introduction P2p
 
protocol architecture
 protocol architecture protocol architecture
protocol architecture
 

Destacado

Computer Network Unit I RGPV
Computer Network Unit I RGPV Computer Network Unit I RGPV
Computer Network Unit I RGPV NANDINI SHARMA
 
Learn BEM: CSS Naming Convention
Learn BEM: CSS Naming ConventionLearn BEM: CSS Naming Convention
Learn BEM: CSS Naming ConventionIn a Rocket
 
10 Insightful Quotes On Designing A Better Customer Experience
10 Insightful Quotes On Designing A Better Customer Experience10 Insightful Quotes On Designing A Better Customer Experience
10 Insightful Quotes On Designing A Better Customer ExperienceYuan Wang
 
How to Build a Dynamic Social Media Plan
How to Build a Dynamic Social Media PlanHow to Build a Dynamic Social Media Plan
How to Build a Dynamic Social Media PlanPost Planner
 
Lightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika Aldaba
Lightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika AldabaLightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika Aldaba
Lightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika Aldabaux singapore
 

Destacado (6)

Computer Network Unit I RGPV
Computer Network Unit I RGPV Computer Network Unit I RGPV
Computer Network Unit I RGPV
 
College Network
College NetworkCollege Network
College Network
 
Learn BEM: CSS Naming Convention
Learn BEM: CSS Naming ConventionLearn BEM: CSS Naming Convention
Learn BEM: CSS Naming Convention
 
10 Insightful Quotes On Designing A Better Customer Experience
10 Insightful Quotes On Designing A Better Customer Experience10 Insightful Quotes On Designing A Better Customer Experience
10 Insightful Quotes On Designing A Better Customer Experience
 
How to Build a Dynamic Social Media Plan
How to Build a Dynamic Social Media PlanHow to Build a Dynamic Social Media Plan
How to Build a Dynamic Social Media Plan
 
Lightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika Aldaba
Lightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika AldabaLightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika Aldaba
Lightning Talk #9: How UX and Data Storytelling Can Shape Policy by Mika Aldaba
 

Similar a Content aware p2 p video streaming with lowlatency

Fast mesh a low-delay high-bandwidth
Fast mesh a low-delay high-bandwidthFast mesh a low-delay high-bandwidth
Fast mesh a low-delay high-bandwidthambitlick
 
A hybrid push pull overlay network for
A hybrid push pull overlay network forA hybrid push pull overlay network for
A hybrid push pull overlay network forijp2p
 
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMINGA HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMINGijp2p
 
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMINGA HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMINGijp2p
 
Mesh pull backup parent pools for video-on-demand multicast trees
Mesh pull backup parent pools for video-on-demand multicast treesMesh pull backup parent pools for video-on-demand multicast trees
Mesh pull backup parent pools for video-on-demand multicast treesIJCNCJournal
 
A dynamic performance-based_flow_control
A dynamic performance-based_flow_controlA dynamic performance-based_flow_control
A dynamic performance-based_flow_controlingenioustech
 
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...csandit
 
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...cscpconf
 
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMINGADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMINGVideoguy
 
Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...
Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...
Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...IBM India Smarter Computing
 
Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...
Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...
Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...Eswar Publications
 
OSI REFRENCE MODEL by- Mujmmil Shaikh
OSI REFRENCE MODEL by- Mujmmil ShaikhOSI REFRENCE MODEL by- Mujmmil Shaikh
OSI REFRENCE MODEL by- Mujmmil ShaikhMujmmil Shaikh
 

Similar a Content aware p2 p video streaming with lowlatency (20)

Fast mesh a low-delay high-bandwidth
Fast mesh a low-delay high-bandwidthFast mesh a low-delay high-bandwidth
Fast mesh a low-delay high-bandwidth
 
A hybrid push pull overlay network for
A hybrid push pull overlay network forA hybrid push pull overlay network for
A hybrid push pull overlay network for
 
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMINGA HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
 
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMINGA HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
A HYBRID PUSH-PULL OVERLAY NETWORK FOR PEER-TO-PEER VIDEO STREAMING
 
Mesh pull backup parent pools for video-on-demand multicast trees
Mesh pull backup parent pools for video-on-demand multicast treesMesh pull backup parent pools for video-on-demand multicast trees
Mesh pull backup parent pools for video-on-demand multicast trees
 
A dynamic performance-based_flow_control
A dynamic performance-based_flow_controlA dynamic performance-based_flow_control
A dynamic performance-based_flow_control
 
report
reportreport
report
 
sac10serviso
sac10servisosac10serviso
sac10serviso
 
Ccna day1
Ccna day1Ccna day1
Ccna day1
 
Ccna day1
Ccna day1Ccna day1
Ccna day1
 
C C N A Day1
C C N A  Day1C C N A  Day1
C C N A Day1
 
Ccna day1
Ccna day1Ccna day1
Ccna day1
 
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
 
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
A NEW ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE BASED...
 
Ccna day1
Ccna day1Ccna day1
Ccna day1
 
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMINGADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
ADVANCES IN CHANNEL-ADAPTIVE VIDEO STREAMING
 
Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...
Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...
Towards an Open Data Center with an Interoperable Network (ODIN) : Volume 2: ...
 
Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...
Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...
Mitigating Link Failures & Implementing Security Mechanism in Multipath Flows...
 
Project titles abstract_2012
Project titles abstract_2012Project titles abstract_2012
Project titles abstract_2012
 
OSI REFRENCE MODEL by- Mujmmil Shaikh
OSI REFRENCE MODEL by- Mujmmil ShaikhOSI REFRENCE MODEL by- Mujmmil Shaikh
OSI REFRENCE MODEL by- Mujmmil Shaikh
 

Último

Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarPrecisely
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 

Último (20)

Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity Webinar
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 

Content aware p2 p video streaming with lowlatency

  • 1. CONTENT-AWARE P2P VIDEO STREAMING WITH LOW LATENCY Pierpaolo Baccichet∗ , Jeonghun Noh† , Eric Setton‡ and Bernd Girod† ∗ Max Planck Center for Visual Computing & Communication, Stanford, CA 94305 † Information Systems Laboratory, Stanford University, Stanford, CA 94305 ‡ Streaming Media Systems Group - Hewlett-Packard Labs, Palo Alto, CA 94306 {bacci,jhnoh,bgirod}@stanford.edu, eric.setton@hp.com ABSTRACT with the number of descriptions received. Alas, MDC introduces substantial redundancy relative to single-description coding. This This paper describes the Stanford P2P Multicast (SPPM) streaming redundancy unnecessarily degrades the rate-distortion performance, system that employs an overlay architecture specifically designed if no packet losses or node failures occur. for low delay video applications. In order to provide interactivity to the user, this system has to keep the end-to-end delay as small as In this paper, we present a tree-based solution that does not re- possible while guaranteeing a high video quality. A set of compli- quire MDC but exploits local retransmission to mitigate packet loss. mentary multicast trees is maintained to efficiently relay video traf- By maintaining multiple distribution trees, it is possible to direct a fic and a Congestion-Distortion Optimized (CoDiO) scheduler pri- retransmission request for a missing packet from a particular tree to oritizes more important video packets. Local retransmission is em- a parent in another distribution tree. Our approach integrates recent ployed to mitigate packet loss. Real-time experiments performed on work done on Congestion-Distortion Optimized packet scheduling the Planet-Lab show the effectiveness of the system and the benefits [6] to prioritize the delivery of video data according to the percep- of a content-aware scheduler in case of congestion or node failures. tual importance. An overview of the protocol is provided in Sec. 2 while the details of system architecture and implementation are reported in Sec. 3. Simulation results obtained on Planet-Lab are 1. INTRODUCTION reported in Sec. 4. In recent years, video streaming over the Internet has become more and more popular due to the increasing availability of bandwidth and recent advances in video coding technologies. In several application 2. OVERLAY MULTICAST PROTOCOL scenarios, such as IP-TV, the same video content has to be transmit- ted to a large population of users. Content Delivery Networks (such The Stanford P2P Multicast (SPPM) protocol organizes peer nodes as Akamai [1]) are often used to support large numbers of users but in an overlay that consists of a set of multicast trees. The source of they require the deployment of special infrastructure. As an alterna- the stream is the root of each distribution path and multiplexes video tive, Peer-to-Peer (P2P) overlay networks have been considered for packets on different trees to ensure load balancing. Fig. 1 shows a delivery of multimedia. The idea is that users who are interested in simple topology with eight peers and two distribution trees as an ex- a video stream can act as relay points and forward the data to other ample of the overlay created by SPPM. In the following, we describe users, thus allowing the system to scale with the number of nodes how our solution maintains the overlay network and guarantees error involved in the communication. P2P systems are widely used for resilience. video file sharing. For live multicasting, however, the problem is much more challenging, as the overlay network must guarantee high reliability of the connections and a constant flow of data, as well as low startup latencies. S Several different architectures have been proposed in the liter- P1 P5 ature that can be grouped in two different categories. Mesh-based approaches (such as GridMedia [2]) aim to construct an overlay mesh whose connections are maintained through “gossiping”. Even P2 though these solutions provide good error resilience and network uti- lization performance, they are usually characterized by high startup delays. This is mostly due to the Push-Pull approach followed in P4 P6 the dissemination of the video data that requires the receivers to co- P3 ordinate the download of different portions of information. On the other hand, Tree-based approaches simply Push video packets along routes that are determined by constructing one [3] or many [4, 5] P7 multicast trees rooted at the media source. These solutions may Tree 1 lead to low latencies but they often assume the source signal to be P8 Tree 2 encoded using Multiple Description Coding (MDC). With this ap- proach independent descriptions can be sent over different network paths. The quality of the reconstruction at the decoder increases Fig. 1. An example overlay that consists of two multicast trees.
  • 2. JOIN PROBE ATTACH 2.1.3. Loop prevention Source Candidate Parents Selected Parent During the reconnection process, a node may attach to one of its descendants. This loop would eventually starve the whole subtree. To prevent this problem, each peer keeps the list of its ancestors. In our implementation, a specific ANCESTOR UPDATE packet allows updating of this list whenever a change in the topology occurs. Peers can easily reject attachment requests issued by an ancestor. This loop avoidance mechanism does not require global knowledge of the New Peer topology but only of a small subset of its nodes. Additional memory and processing power requirements are negligible. Fig. 2. SPPM implements a six-way handshake process to join peers to the session. Each new peer 1) contacts the source, 2) probes a set 2.2. Content-aware scheduling of candidate parents and 3) attaches to a selected parent. Relaying traffic over the uplink of the peers may lead to conges- tion on the multi-hop path separating the source from any particular peer. Because the rate of a video stream often varies, a peer may 2.1. Topology construction and management sometimes lack the resources to forward all the data expected by its A new node joining a multicast first contacts the source to obtain a descendants. When a peer has to drop some packets to ensure timely set of nodes that are already connected to the system. These nodes delivery of the more significant portion of the streams, prioritized are inquired for available resources to determine whether they can scheduling can help maintain video quality. In related work [7], we act as parents in the distribution trees. Since the source of the stream presented a Congestion-Distortion optimized CoDiO packet sched- is continuously online, it can easily manage a database of these con- uler. This prioritization algorithm bases its decisions on the “im- nected peers. The join process consists of a “six-way” handshake as portance” D(n) of each enqueued packet. The metric reflects how described in the following and shown in Fig. 2. decoding of a particular packet reduces distortion and it captures the dependencies among different packets as shown in Fig 3. Hence, the • JOIN. The new peer contacts the source of the video stream scheduler adapts its decisions to the video content by relaying more that replies with some setup information, such as the number important packets first. of multicast trees and the video bit rate. Also, it sends a set of currently connected peers that can be polled as candidate parents. I1 B2 B3 P4 B5 B6 P7 B8 B9 P10 B11 B12 P13 B14 B15 I16 … • PROBE. For each tree, the new peer probes each candidate D(n) 15 1 1 14 1 1 11 1 1 8 1 1 5 1 1 17 parent to obtain their current state and determine the best par- ent to which to connect. Each candidate parent replies provid- Fig. 3. Content-aware packet scheduling can be implemented by ing the available bandwidth and its height in the distribution looking at the interdependencies among video packets. tree. • ATTACH. For each tree, one out of the set of candidate par- ents is selected and an actual connection is established. The 3. SYSTEM ARCHITECTURE parent is selected by minimizing the height of the distribution tree. Also, different parents are chosen as often as possible to We have implemented a real-time prototype of the SPPM protocol exploit path diversity. that uses the state-of-the-art H.264/AVC [8] to efficiently encode the source signal. Video frames are fragmented at the source to a maxi- mum of 1300 bytes to reflect the MTU of a typical ethernet network 2.1.1. Monitoring the connection thus avoiding packet fragmentation in lower layers of the protocol stack. We use UDP as a transport protocol to avoid the overhead in- Once the connection is established, each peer periodically sends volved in the usage of TCP. Two different UDP ports are used for the HELLO REQ messages to the parents in the distribution trees which control and video traffic respectively. A list of the different packet in turn reply with a HELLO REP message. Whenever a host leaves, it types is reported in Table 1. stops forwarding video packets and it is unresponsive to HELLO REQ The software architecture of a SPPM peer is shown in Fig. 4. messages. Thus, peers can detect a parent disconnection and trigger Several threads provide the services needed and the “queue man- the rejoin procedure for the affected tree. Similarly, parent peers ager” and the “routing table” monitors are used for synchronization. record the arrival times of the HELLO REQ messages received by The basic modules are reported in the following. each child, in order to detect children disconnections and release re- sources. • Control Agent is responsible for maintaining the connection to the system. It accepts connection requests from the chil- dren and updates the routing tables accordingly. It periodi- 2.1.2. Local retransmission cally monitors the status of parents by sending HELLO REQ Quality degradation due to packet loss and temporary disconnec- messages and, in case of a disconnection, it triggers the re- tion can be mitigated using retransmission. Note that path diversity connection process. allows retransmission requests to be limited to local parents, thus • Video Agent receives the incoming video packets, retrieves avoiding feedback implosion at the source of the stream. See [7] for from the routing table the list of children to which the packet further details. has to be relayed and then stores it into the video queue.
  • 3. Incoming Video Queue Manager Decoder Video traffic Agent Playout Buffer Video Queue Routing Table Relay Outgoing Control Queue traffic Agent Control Control packets Agent Fig. 4. The SPPM software architecture. Video and control packets received from the network are stored into a common buffer within a Queue Manager that performs prioritization and garbage collection. Packets are then relayed to children or displayed at regular intervals by appropriate playout and relay agents. • Routing table stores the list of children for each tree. 4. EXPERIMENTAL RESULTS • Queue Manager implements a common buffer to store pack- We tested our real-time SPPM prototype on Planet-Lab [9] and per- ets that are to be relayed or displayed. A garbage collector formed experiments using 100 nodes. As a test video, we concate- periodically discards packets that are expired, i.e. that have nate several well-known sequences at CIF resolution at 30 frames passed their playout deadline. per second. We encoded the video using H.264/AVC at 400kbps ob- • Relay Agent periodically extracts from the queue the next taining an average video quality of 34.5 dB of PSNR. In order to packet to be sent and forwards it to the appropriate child. allow users to join at different times, we sent one intra coded frame • Playout Buffer retrieves packets that are to be displayed from every half second. The group of pictures (GOP) was similar to the the video queue and passes them to the video decoder. one shown in Fig. 3. The playout deadline was set to 5 seconds and we used 8 different multicast trees. The source of the video stream implements two additional mod- Each session consisted of 30 minutes of video streaming. The ules that are described in the following. peers were scheduled to randomly connect within the first minute and to stay connected to the system for the whole session. Note • Video Packetizer reads the H.264/AVC input video, either that each node on Planet-Lab shares both link and processing power from a file or from a socket, and performs packet fragmenta- with several other users. In this environment, conditions may vary tion whenever it is necessary. In our implementation, we set quickly possibly causing temporary congestion to occur on the links. the maximum size of a video packet equal to 1300 bytes to reflect the MTU of an Ethernet. 4.1. Video performance • Connected peers’database maintains an approximate list of connected peers. Each entry in the list is refreshed with peri- We show the results of three different experiments to demonstrate the odical information received from the peers via PEER UPDATE effectiveness of the retransmission and prioritization scheme of our packets. If the source fails to receive such packets from a reg- solution. We observed that several nodes fail to provide good video istered peer for a certain amount of time, it considers the peer quality to the user when retransmission and prioritization are not as disconnected from the system and frees the entry in the used. In this case, the PSNR across all the peer is equal to 30.1 dB. A table. significant improvement is observed after introducing retransmission with an average quality of 31.8 dB while the best performance of 3.1. NAT Support 33.2 dB was obtained by combining retransmission with the content- aware packet scheduler described in Sec. 2.2. Fig. 5 shows the A vast majority of residential users access the Internet via some kind average video quality observed at selected peers. of Network Address Translator (NAT) device that usually filters un- Whenever a peer fails to receive data for a certain amount of solicited incoming traffic directed to nodes of the local network. A time, the video decoder performs error concealment by displaying NAT will forward incoming traffic from a specific IP address only previously received frames in lieu of the lost ones. Long frame if a packet has been sent to that IP address before. In order to sup- freezes can be considered an indication of a failure in the connec- port devices behind NATs, our “six-way” handshake procedure has tion to the system and must be limited. We observed a significant to be slightly modified because the PROBE REQ messages would be decrease in the number of frame freezes by using retransmission and normally filtered as unsolicited traffic. We assume the source of the prioritization, as reported in Table 2. stream to be running on a computer with a static IP address. When the source receives a join request, it can detect the public address of 4.2. Startup delay the new peer and send this information to the set of potential can- didate parents. The parents then transmit a dummy packet to the The main design goal of our solution is to provide high video quality control port of the new peer. This creates a binding on the NAT with very low latency. To validate the effectiveness of the implemen- device that will enable the forwarding of subsequent PROBE REQ tation, we recorded the minimum startup delay necessary to receive messages. the first decodable picture at each peer. We observed an average
  • 4. Type Size Description JOIN REQ 40 Join request is sent by the new peer to the source. JOIN REP 200+ Join reply contains setup information and list of candidate parents. PROBE REQ 32 Probe request is sent to every candidate parent to collect information about the current status. PROBE REP 40 Probe reply contains information regarding the current status of the candidate parent. ATTACH REQ 40 Attach request is used to establish the actual connection with the selected parent. ATTACH REP 40 Attach reply confirms the established connection. HELLO REQ 36 Hello request sent to periodically monitor the state of the parent. HELLO REP 40 Hello reply is used to disseminate information about the end-to-end delay from the source. PEER UPDATE 60 Status information periodically sent to the source to update the list of connected peers. ANCESTOR UPDATE 60+ Propagates the list of ancestors on each tree to avoid creation of loops. Table 1. Summary of the packet types used by SPPM. Sizes are expressed in bytes and include the overhead due to UDP/IP. 35 5. CONCLUSIONS No retr. 34 Retr. In this paper, we reported the design and implementation of the Stan- Retr. + Prio. ford Peer-to-Peer Multicast - SPPM protocol that allows the delivery No retr. Retr. Retr. + Prio. 33 umontreal.ca 30,40 32,05 32,87 of a video stream from a source to a population of users with very PSNR [dB] osaka-u.ac.jp 29,86 31,56 32,75 low delay. Experimental results obtained on the Planet-Lab confirm rochester.edu 31,30 32,75 32,74 the effectiveness of the protocol. Startup delay was measured on the 32 duke.edu 30,20 31,50 33,98 order of one second (on average). Video quality was improved by sunysb.edu 31,03 32,05 33,89 2dB on average by introducing a Congestion-Distortion Optimized uni-hannover.de 31 30,23 31,74 33,85 stanford.edu 29,30 31,45 33,98 packet scheduler and local retransmission. utoronto.ca 31,95 31,98 32,76 30 washington.edu 29,80 31,89 33,65 cornell.edu 30,19 32,15 32,90 6. REFERENCES pbs.org 29,50 31,98 33,04 29 utexas.edu 28,90 30,66 32,84 [1] “Akamai,” http://www.akamai.com. stir.ac.uk 30,72 31,50 32,89 un uny du no du k u du st d u ex rg es .jp a- ca wa oro du fo de du du g t ca .u co . e d u t s.o ch a c .e . . a n .e .e l.e .e . r.e ac [2] M. Zhang, J. Luo, L. Zhao, and S. Yang, “A peer-to-peer al sh n t o 30,26 31,79 33,24 st ver ke sb as on rd re u. el pb ir. te rn t on network for live media streaming using a push-pull approach,” an ak in ut um s os i-h ro Proc. of the 13th annual ACM international conference on Mul- timedia, pp. 287–290, 2005. Fig. 5. Average PSNR measured over 30 minutes of video on Planet- [3] Y. Chu, S. Gao, and H. Zhang, “A case for end system multi- Lab for 13 sample nodes. cast,” Proc. ACM Sigmetrics, Santa Clara USA, June 2000. [4] M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi, A. Row- Scheme 0.5 to 1 to More than stron, and A. Singh, “SplitStream: High-bandwidth content dis- 1 sec. 2 sec. 2 sec. tribution in a cooperative environment,” Proc. IPTPS’03, Berke- No retransmission 4262 1784 457 ley, CA, Feb. 2003. Retransmission 742 283 127 [5] V. N. Padmanabhan, H. J. Wang, P. A. Chou, and K. Sripanid- Retrans. & Prioritization 364 143 43 kulchai, “Distributing Streaming Media Content Using Coop- erative Networking,” Proc. ACM NOSSDAV, Miami Beach, FL, Table 2. Number and duration of the observed frame freezes for the May 2002. three considered scenarios over 100 different peers. [6] E. Setton, “Congestion-Aware Video Streaming over Peer-to- Peer Networks,” Ph.D. Thesis, Stanford University. startup delay of one second. All the peers connected to the system [7] E. Setton, J. Noh, and B. Girod, “Rate-Distortion Optimized within two seconds from the join request. Video Peer-to-Peer Multicast Streaming,” Workshop on Ad- vances in Peer-to-Peer Multimedia Streaming at ACM Multime- dia, Singapore, pp. 39–48, Nov. 2005. 4.3. Protocol overhead [8] ITU-T and ISO/IEC JTC 1, Advanced Video Coding for Generic The SPPM protocol introduces a very small control overhead to Audiovisual services, ITU-T Recommendation H.264 - ISO/IEC manage the overlay. We recorded the size and number of packets ex- 14496-10(AVC), 2003. changed, including the overhead due to UDP/IP encapsulation. We [9] “Planet-Lab,” http://www.planet-lab.org. observed control packets are no more than 4% of the total traffic. If we consider the additional header information introduced for each video packet, i.e., sequence numbers and timestamps, the overhead of the protocol is smaller than 8% of the total traffic.