Scalable Packet Loss Recovery for Mobile P2P Streaming

Transcription

1 1 Scalable Packet Loss Recovery for Mobile P2P Streaming Jani Peltotalo, Jarmo Harju, Lassi Väätämöinen (Tampere University of Technology) Igor D. D. Curcio, Imed Bouazizi, Joep van Gassel (Nokia Research Center) 8th International Conference on Wired/Wireless Internet Communications (WWIC 2010) June , Luleå, Sweden

2 Background: RTSP-based Mobile Peer-to-Peer Streaming System 2 Jani Peltotalo, Jarmo Harju, Lassi Väätämöinen, Igor D.D. Curcio, and Imed Bouazizi, RTSP-based Mobile Peer-to-Peer Streaming System, in International Journal of Digital Multimedia Broadcasting, Volume 2010, Article ID , 15 pages, doi: /2010/ The basis for the system is a scalable overlay network which groups peers into clusters according to their proximity Round Trip Time (RTT) values between peers used as a criteria for the cluster selection All overlay network operations done using Real Time Streaming Protocol (RTSP) Media data exchange between peers using Real-time Transport Protocol (RTP) streams Partial RTP stream concept

3 3 System Overview: Overlay Architecture

4 4 System Overview: Partial RTP Streams An RTP multimedia session is divided into smaller pieces along the time axis An RTP packet can be mapped to a partial stream using timestamp t RTP and two parameters: Piece duration T P Number of partial streams N

5 5 System Overview: Media Delivery

6 6 RTCP-based Packet Loss Recovery Generic NACK RTCP messages are used to signal packet losses from the receiver to the sender in a traditional streaming application. - RTCP is only suitable for requesting retransmission of data in the case where the sending peer is still available - Peer does not explicitly request retransmission; it only signals which packets have been lost to the sender, and it is up to the sender to decide how to deal with this information + RTCP is already in place in most implementations + The amount of overhead is small, since the Generic NACK messages are sent along with the normal RTCP RRs in compound RTCP messages

7 7 RTSP-based Packet Loss Recovery Alternatively to the RTCP-based packet loss signaling, the RTSP PLAY message can be used for requesting retransmission of lost packets. - Current syntax of the Range header field does not allow requesting retransmission of individual packets or a limited set of packet ranges; it allows time-based ranges but these do not suffice to uniquely identify single packets - More message overhead and latencies + Peer will always receive information about the sender's capability to actually retransmit the requested packets

8 8 Scalable Two-Stage Packet Loss Recovery 1. Use RTCP in the normal and extended way to signal packet losses to the sending peers 2. In case lost packets are not received during a certain time-out value use RTSP to set up new connections and to request the retransmission of the missing packets In combination with the above mentioned two stages, a special signaling of pending retransmission requests and resolved packet losses can be applied to enhance the scalability

9 9 Avoiding Retransmission Request Overload 1. The signaling of pending retransmission requests downstream In the absence of packets, the information is signaled to indicate to the receiving peers that the sender is aware of the losses 2. The signaling of the recovered packets both downstream and upstream Information can be utilized by the recipients to efficiently reconnect to other peers which have signaled that they have resolved the problem

10 Scalable Two-Stage Packet Loss Recovery: Peer Operation 10

11 11 Performance Evaluation: Test Setup Laboratory network environment has been utilized to evaluate the operation of the P2P streaming system with and without the RTSP-based packet loss recovery mechanism Currently our P2P streaming system contains only an RTSP-based packet loss recovery mechanism (in addition to the normal peer replacement) 16 hosts were used to run 40 peers in each host together with one host acting as an original data source The length for one live streaming service was roughly one hour Stream bit rate 112 kbps (H.263 video + AAC audio) T P was 100 ms for audio stream and 400 ms for video stream N was one for audio stream and four for video stream Two test cases Churning peers 1% uniformly distributed packet loss

12 12 Churning Peers: Audio Stream Without packet loss recovery With packet loss recovery

13 13 Churning Peers: Video Stream Without packet loss recovery With packet loss recovery

14 14 1% Packet Loss: Audio Stream Without packet loss recovery With packet loss recovery

15 15 1% Packet Loss: Video Stream Without packet loss recovery With packet loss recovery

16 16 RTSP Data: Churning Peers Without packet loss recovery With packet loss recovery

17 17 RTSP Data: 1% Packet Loss Without packet loss recovery With packet loss recovery

18 18 Conclusions The traditional RTCP-based packet loss signaling is insufficient in the peer-to-peer streaming If sender completely leaves the network, it does not make sense to signal lost packets since they will never be received by the departed sender Laboratory tests with the current RTSP-based packet loss recovery mechanism have shown that it is beneficial to try to ensure seamless media playback using packet retransmissions Full implementation level support for the two-stage packet loss recovery mechanism is still needed Verify the operation of the packet loss recovery mechanism Fine tune all parameters in the system More advanced laboratory tests with different latencies, packet losses and throughputs between peers will highlight possible bottlenecks and usability issues

19 19 Questions? Scalable Packet Loss Recovery for Mobile P2P Streaming