Multimedia Streaming on Heterogeneous Networks: QoS and Protocols

1. 教育部行動寬頻尖端技術人才培育計畫-小細胞基站聯盟中心教育部行動寬頻尖端技術人才培育計畫-小細胞基站聯盟中心 「小基站與WiFi之異質性網路存取」課程模組 單元5多媒體影音串流在異質性網路上的QoS 助理教授：吳俊興 助教：吳振宇 國立高雄大學 資訊工程學系

2. Outline • Overview • Streaming Multimedia • Protocols for Real-time Conversational Applications • Network Support for Multimedia • LTE Quality of Service • QoS Measurements • Summary Reference: Jim Kurose, Keith Ross, Computer Networking: A Top Down Approach 7th Edition, Pearson, 2016

3. Properties of Heterogeneous Wireless Networks • Benefit: expand the network capacity and coverage in a dynamic fashion • Challenge: Quality of Service (QoS) evaluation is very challenging due to the presence of different communication technologies • Different communication technologies have different characteristics • different performance measurement parameters • The applications that utilize them have unique QoS requirements • They may use different radio access networks but have the same QoS requirements

4. QoS • Three types of QoS: intrinsic, perceived and assessed • Intrinsic QoS is directly provided by the network itself and may be described in terms of objective parameters as, for instance, loss and delay • Perceived QoS (P-QoS) is the quality perceived by the users; • It is measured by the “average opinion” of the usersby assigning Mean Opinion Score (MOS) rating (1 to 5) • Assessed QoS is the will of a user to keep on using a specific service • Most of the QoS provision is offered in terms of intrinsic (objective parameters) QoS by using a Service Level Specification (SLS) which is “a set of parameters and their values which together define the service offered to a traffic” [RFC3206]

5. QoS Class Proposed by ITU-T Recommendation

6. QoS Class Proposed by ETSI-TR102

7. Typical QoS Parameters • Latency / delay • Jitter • Bandwidth / Bit rate • Loss • Throughput / Admission rate

8. IP QoS Classes andObjective Performance-metric Upper Limits • IPTD– IP Packet Transfer Delay • IPDV– IP Packet Delay Variation (known as Jitter) • IPLR – IP Packet Loss Ratio • IPER– IP Packet Error Ratio

9. Example of QoS Service Level Specification

10. Outline • Overview • Streaming Multimedia • Protocols for Real-time Conversational Applications • Network Support for Multimedia • LTE Quality of Service • QoS Measurements • Summary

11. Multimedia Networking Applications • Audio • Analog audio signal sampled at constant rate • Telephone: 8,000 samples/sec • CD music: 44,100 samples/sec • Each sample quantized, i.e., rounded • Each quantized value represented by bits, e.g., 8 bits for 256 values • Video • Sequence of images displayed at constant rate • Digital image: array of pixels • Each pixel represented by bits • Coding: use redundancy within and between images to decrease bits used to encode image • Spatial (within image) • Temporal (from one image to next)

12. Multimedia: Audio and Video spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N) quantization error ……………………...… quantized value of analog value ……………………...… analog signal audio signal amplitude frame i time sampling rate (N sample/sec) temporal coding example: instead of sending complete frame at i+1, send only differences from frame i frame i+1

13. Multimedia Networking: 3 Application Types • Streaming, storedaudio, video • Streaming: can begin playout before downloading entire file • Stored (at server): can transmit faster than audio/video will be rendered (implies storing/buffering at client) • e.g., YouTube, Netflix, Hulu • Conversational voice/video over IP • Interactive nature of human-to-human conversation limits delay tolerance • e.g., Skype • Streaming live audio, video • e.g., live sporting event (futbol)

14. 2. video sent • video • recorded (e.g., 30 frames/sec) 3. video received, played out at client (30 frames/sec) network delay (fixed in this example) streaming: at this time, client playing out early part of video, while server still sending later part of video Streaming Stored Video Cumulative data time

15. Challenges Of Streaming Stored Video • Continuous playout constraint: once client playout begins, playback must match original timing • Network delays are variable (jitter), so will need client-side buffer to match playout requirements • Other challenges: • Client interactivity: pause, fast-forward, rewind, jump through video • Video packets may be lost, retransmitted

16. client video reception constant bit rate video playout at client variable network delay buffered video client playout delay Streaming Stored Video: Revisited • Client-side buffering and playout delay: compensate for network-added delay, delay jitter constant bit rate video transmission Cumulative data time

17. Client-side Buffering, Playout buffer fill level, Q(t) • Initial fill of buffer until playout begins at tp • Playout begins at tp • Buffer fill level varies over time as fill rate x(t) varies and playout rate r is constant playout rate, e.g., CBR r variable fill rate, x(t) client application buffer, size B video server client

18. Playout Buffering buffer fill level, Q(t) Average fill rate (x), playout rate (r): • x < r: buffer eventually empties (causing freezing of video playout until buffer again fills) • x > r: buffer will not empty, provided initial playout delay is large enough to absorb variability in x(t) • Initial playout delay tradeoff: buffer starvation less likely with larger delay, but larger delay until user begins watching playout rate, e.g., CBR r variable fill rate, x(t) client application buffer, size B video server client

19. Streaming Multimedia: UDP • Server sends at rate appropriate for client • Often: send rate = encoding rate = constant rate • Transmission rate can be oblivious to congestion levels • Short playout delay (2-5 seconds) to remove network jitter • Error recovery: application-level, time permitting • RTP [RFC 2326]: multimedia payload types • UDP may not go through firewalls

20. Streaming Multimedia: HTTP • Multimedia file retrieved via HTTP GET • Send at maximum possible rate under TCP • Fill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery) • Larger playout delay: smooth TCP delivery rate • HTTP/TCP passes more easily through firewalls variable rate, x(t) video file TCP send buffer TCP receive buffer application playout buffer server client

21. Voice-over-IP (VoIP) • VoIP end-end-delay requirement: needed to maintain “conversational” aspect • Higher delays noticeable, impair interactivity • < 150 msec: good • > 400 msec: bad • Includes application-level (packetization, playout), network delays • Session initialization: how does callee advertise IP address, port number, encoding algorithms? • Value-added services: call forwarding, screening, recording • Emergency services: 119

22. VoIP Characteristics • Speaker’s audio: alternating talk spurts, silent periods • 64 kbps during talk spurt • pkts generated only during talk spurts • 20 msec chunks at 8 Kbytes/sec: 160 bytes of data • Application-layer header added to each chunk • Chunk+headerencapsulated into UDP or TCP segment • Application sends segment into socket every 20 msec during talkspurt

23. VoIP: Packet Loss, Delay • Network loss: IP datagram lost due to network congestion (router buffer overflow) • Delay loss: IP datagram arrives too late for playout at receiver • Delays: processing, queueing in network; end-system (sender, receiver) delays • Typical maximum tolerable delay: 400 ms • Loss tolerance: depending on voice encoding, loss concealment, packet loss rates between 1% and 10% can be tolerated

24. client reception constant bit rate playout at client variable network delay (jitter) buffered data client playout delay Delay Jitter • End-to-end delays of two consecutive packets: difference can be more or less than 20 msec (transmission time difference) constant bit rate transmission Cumulative data time

25. VoIP: Fixed Playout Delay • Receiver attempts to playout each chunk exactly qmsecs after chunk was generated • Chunk has time stamp t: play out chunk at t+q • Chunk arrives after t+q: data arrives too late for playout: data “lost” • Tradeoff in choosing q: • Large q: less packet loss • Small q:better interactive experience

26. Playout Schedule • Sender generates packets every 20 msec during talk spurt • First packet received at time r • First playout schedule: begins at p • Second playout schedule: begins at p’

27. Adaptive Playout Delay • Goal:low playout delay, low late loss rate • Approach:adaptive playout delay adjustment: • Estimate network delay, adjust playout delay at beginning of each talk spurt • Silent periods compressed and elongated • Chunks still played out every 20 msec during talk spurt • Adaptively estimate packet delay: (EWMA - exponentially weighted moving average, recall TCP RTT estimate): di = (1-a)di-1 + a (ri – ti) delay estimate after ith packet small constant, e.g. 0.1 time sent (timestamp) time received - measured delay of ith packet

28. Estimate Playout Delay • Also useful to estimate average deviation of delay, vi: • Estimates di, vicalculated for every received packet, but used only at start of talk spurt • For first packet in talk spurt, playout time is: • Remaining packets in talkspurt are played out periodically vi = (1-b)vi-1 + b |ri – ti – di| playout-timei = ti + di + Kvi

29. Recovery From Packet Loss Recover from packet loss given small tolerable delay between original transmission and playout • Each ACK/NAK takes ~ one RTT • Alternative: Forward Error Correction (FEC) • send enough bits to allow recovery without retransmission Simple FEC • For every group of n chunks, create redundant chunk by exclusive OR-ingn original chunks • Send n+1 chunks, increasing bandwidth by factor 1/n • Can reconstruct original n chunks if at most one lost chunk from n+1 chunks, with playout delay

30. Another FEC Scheme • Piggyback lower quality stream • Send lower resolution audio stream as redundant information • Non-consecutive loss: receiver can conceal loss • Generalization: can also append (n-1)st and (n-2)nd low-bit rate chunk

31. Interleaving to Conceal Loss • Audio chunks divided into smaller units • e.g. four 5 msec units per 20 msec audio chunk • Packet contains small units from different chunks • If packet lost, still have most of every original chunk • No redundancy overhead, but increases playout delay

32. Outline • Overview • Streaming Multimedia • Protocols for Real-time Conversational Applications • Network Support for Multimedia • LTE Quality of Service • QoS Measurements • Summary

33. Protocols for Real-time Conversational Applications: RTP, SIP • Real-Time Protocol (RTP) [RFC 3550] • RTP specifies packet structure for packets carrying audio, video data • RTP runs in end systems • RTP packets encapsulated in UDP segments • Interoperability: if two VoIP applications run RTP, they may be able to work together • SIP: Session Initiation Protocol [RFC 3261] • SIP provides mechanisms for call setup • Determine current IP address of callee • Call management

34. RTP Runs on Top of UDP • RTP libraries provide transport-layer interface • That extends UDP: • Port numbers, IP addresses • Payload type identification • Packet sequence numbering • Time-stamping

35. RTP and QoS • RTP does not provide any mechanism to ensure timely data delivery or other QoS guarantees • RTP encapsulation only seen at end systems (not by intermediate routers) • Routers provide best-effort service, making no special effort to ensure that RTP packets arrive at destination in timely matter

36. Real-Time Control Protocol (RTCP) • Works in conjunction with RTP • Each participant in RTP session periodically sends RTCP control packets to all other participants • Each RTCP packet contains sender and/or receiver reports • Report statistics useful to application: # packets sent, # packets lost, inter-arrival jitter • Feedback used to control performance • Sender may modify its transmissions based on feedback

37. Multiple Multicast Senders sender • Each RTP session • Typically a single multicast address • All RTP /RTCP packets belonging to session use multicast address • RTP, RTCP packets distinguished from each other via distinct port numbers • To limit traffic • Each participant reduces RTCP traffic as number of conference participants increases RTCP RTCP RTCP receivers RTP

38. Stream Synchronization • RTCP can synchronize different media streams within a RTP session • e.g., videoconferencing app: each sender generates one RTP stream for video, one for audio • Timestamps in RTP packets tied to the video, audio sampling clocks • Not tied to wall-clock time • Each RTCP sender-report packet contains (for most recently generated packet in associated RTP stream) • Timestamp of RTP packet • Wall-clock time for when packet was created • Receivers uses association to synchronize playout of audio, video

39. Session Initiation Protocol (SIP) • All telephone calls, video conference calls take place over Internet • People identified by names or e-mail addresses, rather than by phone numbers • Can reach callee (if callee so desires) • No matter where callee roams • No matter what IP device callee is currently using

40. Setting Up Call to Known IP Address • SIP messages can be sent over TCP or UDP • Here sent over RTP/UDP • Media can be sent over RTP or some other protocol

41. Comparison with H.323 • H.323 • Another signaling protocol for real-time, interactive multimedia • Complete, vertically integrated suite of protocols for multimedia conferencing • Signaling, registration, admission control, transport, codecs • Comes from the ITU (telephony) • SIP • Single component • Works with RTP, but does not mandate it • Can be combined with other protocols, services • Comes from IETF, borrows much of its concepts from HTTP • Uses KISS(Keep It Simple Stupid) principle

42. Outline • Overview • Streaming Multimedia • Protocols for Real-time Conversational Applications • Network Support for Multimedia • Quality of Service • QoS Measurements • Summary

43. Network Support for Multimedia

44. Providing Multiple Classes of Service • One-size fits all service model • Partition traffic into classes • Network treats different classes of traffic differently • Differential service among multiple classes, not among individual connections 1.5 Mbps link H3 H1 R1 R2 H4 R1 output interface queue H2 0111

45. Principles for QoS Guarantees • Packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly • Provide protection (isolation) for one class from others R1 R2 1 Mbps phone R1 R2 1.5 Mbps link packet marking and policing

46. Principles for QoS Guarantees (Cont.) • While providing isolation, it is desirable to use resources as efficiently as possible • Allocating fixed (non-sharable) bandwidth to flow • Inefficient use of bandwidth if flows doesn’t use its allocation • Call admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs 1 Mbps logical link 1 Mbps phone R1 R2 1.5 Mbps link 0.5 Mbps logical link 1 Mbps phone R1 R2 1.5 Mbps link 1 Mbps phone

47. Policing Mechanisms • Limit traffic to not exceed declared parameters • Three common-used criteria • Average rate: how many pkts can be sent per unit time (in the long run) • Peak rate • Burst size: max number of pkts sent consecutively (with no intervening idle) token bucket: limit input to specified burst size and average rate

48. D = b/R max Policing and QoSGuarantees • Token bucket, WFQ combine to provide guaranteed upper bound on delay arriving traffic token rate, r bucket size, b per-flow rate, R WFQ arriving traffic

49. scheduling marking Differentiated Services . r . . b • Scalability:simple functions in network core, relatively complex functions at edge routers (or hosts) • Signaling, maintaining per-flow router state difficult with large number of flows • Don’t define service classes, provide functional components to build service classes

50. Outline • Overview • Streaming Multimedia • Protocols for Real-time Conversational Applications • Network Support for Multimedia • LTE Quality of Service • QoS Measurements • Summary