Lec 18 - Multimedia Transport: Congestion Control

Transcription

1 ECE 5578 Multimedia Communication Lec 18 - Multimedia Transport: Congestion Control Zhu Li Dept of CSEE, UMKC Office: FH560E, lizhu@umkc.edu, Ph: x slides created with WPS Office Linux and EqualX LaTex equation editor Z. Li, Multimedia Communciation, 2018 p.1

2 Outline ReCap Lecture 17 Congestion Models and Control TCP and TCP Friendly Congestion Model New Congestion Work at RMCAT Summary Z. Li, Multimedia Communciation, 2018 p.2

3 Adv. DASH Features MP4Box/DASH.js MP4Box is a versatile tool for media file manipulation, it has functionality built in for preparing DASH streaming content DASH.js is a reference javascript DASH client implementation, by the DASH IF, and easy to modify and good for research PoC <script src=" </script> <h4> DASH.js Player Demo </h4> <style> video { width: 640px; height: 360px; }</style>. <div> <video data-dashjs-player src=" h3/manifest.mpd" controls></video> </div> Z. Li, Multimedia Communciation, 2018 p.3

4 Adv. DASH Features DASH FDH Improve throughput, efficiency by utilizing new transport HTTP 2.0/WebSocket has different APIs but fundamentally the same implementation Ref: DASH FDH specs Z. Li, Multimedia Communciation, 2018 p.4

5 Adv. DASH Features DASH SAND Allows server and other DANE middle box to play a role New messaging to report QoS, QoE, and coordinate, accelerate traffic Ref: DASH SAND specs Z. Li, Multimedia Communciation, 2018 p.5

6 Outline ReCap Lecture 17 Congestion Models and Control TCP and TCP Friendly Congestion Model New Congestion Work at RMCAT Summary Z. Li, Multimedia Communciation, 2018 p.6

7 Media Transport over the IP Networks RTP, RTCP, RTSP get UDP port RTSP server data source media server RTSP SETUP RTSP OK RTSP PLAY RTSP OK RTSP TEARDOWN RTSP OK RTP VIDEO RTP AUDIO RTCP TCP UDP RTSP client AV subsyste m media player choose UDP port Z. Li, Multimedia Communciation, 2018 p.7

8 RTP Header RTP Header Payload type Incremented by one for each RTP PDU: PDU loss detection Restore PDU sequence Identifies synchronization sourceidentifies contributing sources (used by mixers) Z. Li, Multimedia Communciation, 2018 p.8

9 HTTP History Evolution of Web Content Transport: Persistent connections Virtual host support Conditional caching Digest authentication Chunked transfer encoding Enhanced compression Header compression Security requirements Interleaving requests and responses Push operations Binary instead of textual 1996 HTTP HTTP SPDY HTTP 2.0 Rise of the Internet as a Platform Web 2.0 Cloud Mobility Z. Li, Multimedia Communciation, 2018 p.9

10 SPDY / HTTP 2.0 Work Still works on top of a TCP connection Slow start (mitigated by changing init cwnd size to 16) Head of Line (HOL) blocking: o Another disadvantage of SPDY is that an out-of-order packet delivery for TCP induces head of line blocking for all the SPDY streams multiplexed on that TCP connection. Connection Latency: 3 RTT to establish a secure link Under utilization of link capacity by TCP Rate Control no loss, in order delivery, not that a big deal for media data (we have CTS/DTS) Z. Li, Multimedia Communciation, 2018 p.10

11 CDN and Web Cache Forward and Reverse Proxy Fwd: intercept client request, serve locally if can Rev: intercept server request, serve transparent of client if can Research Issues Rate Agnostic Content Identification! Fragmentation IRTF ICN/CCN work!: Fwd Proxy Rev Proxy Z. Li, Multimedia Communciation, 2018 p.11

12 WebRTC WebRTC is a browser embedded native audio/visual real time streaming solution Built on top of RTP Have firewall traversal support Widely deployed in Chrome and Firefox Main Utilities: MediaStreams access to user's camera and mic PeerConnection audio/video calls DataChannels p2p application data transfer More to come in RMCAT coverage! Z. Li, Multimedia Communciation, 2018 p.12

13 QUIC Quick UDP Internet Connection Main QUIC Features/Design Goals: Connection establishment latency Improved congestion control more suited for media QoE Multiplexing without head-of-line blocking Forward Error Correction (FEC) reduce delay. Connection migration: native support for multipath via CID (Connection ID) Z. Li, Multimedia Communciation, 2018 p.13

14 Outline ReCap Lecture 17 Congestion Models and Control TCP and TCP Friendly Congestion Model New Congestion Work at RMCAT Summary Z. Li, Multimedia Communciation, 2018 p.14

15 TCP Design To provide a reliable byte stream service Error Free, In order delivery Ethernet Hdr - 20 bytes (big-endian) IP Header - 20 bytes (big-endian) TCP Header - 20 bytes (big-endian) App. Hdr & Data Z. Li, Multimedia Communciation, 2018 p.15

16 TCP Connection 3-Way Hand Shake Flag bits get set Syn (only) Syn + Ack Ack Ack( Push, Urgent) Ack( Push, Urgent) Client Server Z. Li, Multimedia Communciation, 2018 p.16

17 TCP Disconnect TCP Tear Down Ack( Push, Urgent) Ack( Push, Urgent) Fin + Ack Ack Fin + Ack Ack Host A or Reset + Ack Host B Either A or B can be the Server Z. Li, Multimedia Communciation, 2018 p.17

18 TCP Transmission Windowed Control Transmit and then wait for ACK: Only one TCP segment is in flight at a time Especially bad when delay-bandwidth product is high Numerical example 1.5 Mbps link with a 45 msec round-trip time (RTT) o Delay-bandwidth product is 67.5 Kbits (or 8 KBytes) But, sender can send at most one packet per RTT o Assuming a segment size of 1 KB (8 Kbits) o leads to 8 Kbits/segment / 45 msec/segment 182 Kbps o That s just one-eighth of the 1.5 Mbps link capacity Packet Size Delay*Bandwidth Z. Li, Multimedia Communciation, 2018 p.18

19 Sliding Window Allow a larger amount of data in flight Allow sender to get ahead of the receiver though not too far ahead Sending process Receiving process TCP Last byte written TCP Last byte read Last byte ACKed Last byte sent Next byte expected Last byte received Z. Li, Multimedia Communciation, 2018 p.19

20 Receiver Buffering Window size Amount that can be sent without acknowledgment Receiver needs to be able to store this amount of data Receiver advertises the window to the receiver Tells the receiver the amount of free space left and the sender agrees not to exceed this amount Window Size Data ACK d Outstanding Un-ack d data Data OK to send Data not OK to send yet Z. Li, Multimedia Communciation, 2018 p.20

21 The Congestion Window In order to deal with congestion, a new state variable called CongestionWindow is maintained by the source. (CWND) Limits the amount of data that it has in transit at a given time. MaxWindow = Min(Advertised Window, CongestionWindow) EffectiveWindow = MaxWindow - (LastByteSent -LastByteAcked). TCP sends no faster than what the slowest component -- the network or the destination host --can accommodate. Z. Li, Multimedia Communciation, 2018 p.21

22 Managing the Congestion Window Decrease window when TCP perceives high congestion. Increase window when TCP knows that there is not much congestion. How? Since increased congestion is more catastrophic, reduce it more aggressively. Increase is additive, decrease is multiplicative -- called the Additive Increase/Multiplicative Decrease (AIMD) behavior of TCP. Z. Li, Multimedia Communciation, 2018 p.22

23 AIMD Each time congestion occurs - the congestion window is halved. Example, if current window is 16 segments and a timeout occurs (implies packet loss), reduce the window to 8. Finally window may be reduced to 1 segment. Window is not allowed to fall below 1 segment (MSS). For each congestion window worth of packets that has been sent out successfully (an ACK is received), increase the congestion window by the size of a (one) segment. Source Destination Z. Li, Multimedia Communciation, 2018 p.23

24 AIMD Remember that TCP is byte oriented. does not wait for an entire window worth of ACKs to add one segment worth to congestion window. Reality: TCP source increments congestion window by a little for each ACK that arrives. Increment = MSS * (MSS/Congestion Window) o This is for each segment of MSS acked. Congestion Window + = Increment. Thus, TCP demonstrates a sawtooth behavior! Time (seconds) 10.0 Z. Li, Multimedia Communciation, 2018 p.24

25 TCP Slow Start Additive Increase is good when source is operating at near close to the capacity of the network. Too long to ramp up when it starts from scratch. Slow start --> increase congestion window rapidly at cold start. Slow start allows for exponential growth in the beginning. E.g. Initially CW =1, if ACK received, CW = 2. If 2 ACKs are now received, CW = 4. If 4 ACKs are now received, CW =8 and so on. Note that upon experiencing packet loss, multiplicative decrease takes over. RTT Host A Host B one segment two segments four segments time Z. Li, Multimedia Communciation, 2018 p.25

26 Why Call it Slow Start? The original version of TCP suggested that the sender transmit as much as the Advertised Window permitted. Routers may not be able to cope with this burst of transmissions. Slow start is slower than the above version -- ensures that a transmission burst does not happen at once. Z. Li, Multimedia Communciation, 2018 p.26

27 TCP Tahoe Loss based: When CW is below the threshold, CW grows exponentially When it is above the threshold, CW grows linearly. Upon time-out, set new threshold to half of current CW and the CW is reset to 1. This version of TCP is called TCP Tahoe. Z. Li, Multimedia Communciation, 2018 p.27

28 TCP Reno Fast retransmit: After receiving 3 duplicate ACK Resend first packet in window. o Try to avoid waiting for timeout Fast recovery: After retransmission do not enter slowstart. Threshold = Congwin/2 Congwin = 3 + Congwin/2 Each duplicate ACK received Congwin++ After new ACK o Congwin = Threshold o return to congestion avoidance Single packet drop: great! Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 Sender Retransmit packet 3 Receiver ACK 1 ACK 2 ACK 2 ACK 2 ACK 2 ACK 6 Z. Li, Multimedia Communciation, 2018 p.28

29 TCP Reno Reno Features Fast Retransmit: after receiving 3 ACK on the same packet Fast Recovery: CWnd andthres adjustment CWnd Time Out Cong Avoidance Timeouts may still occur AIMD Initial Slowstart Slowstart to pace packets Fast Retransmit and Recovery Time Z. Li, Multimedia Communciation, 2018 p.29

30 TCP Vegas Idea: Delay Based Control, track the RTT Try to avoid packet loss latency increases: lower rate latency very low: increase rate Implementation: sample_rtt: current RTT Base_RTT: min. over sample_rtt Expected Rate= CWnd/ Base_RTT Actual Rate = number of packets sent / sample_rtt =Expected - Actual Z. Li, Multimedia Communciation, 2018 p.30

31 TCP Vegas Congestion Control = Expected - Actual Congestion Avoidance: introduce two threshold, and two parameters: and, < If ( < ) Congwin = Congwin +1 If ( > ) Congwin = Congwin -1 Otherwise no change Note: Once per RTT Slowstart parameter If ( > ) then move to congestion avoidance Actual Expected Z. Li, Multimedia Communciation, 2018 p.31

32 TCP Throughput TCP Rate at steady state Segment size: MSS Round Trip Delay: RTT Prob of packet loss: p Observation Reducing RTT is the key! Indeed, AKAMAI, Netflix,,etc, use RTT as the KPI for deploying and provisioning CDN edge servers. Prob of loss is due to congestion, mostly. For wireless networks, loss due to PHY layer has wrong interpretation in TCP control! Z. Li, Multimedia Communciation, 2018 p.32

33 TCP Summary TCP Features Widely deployed transport solution over the current Internet Reliable byte stream service Loss based congestion control: TCP Reno, Tahoe Delay based congestion control: TCP Vegas TCP as media transport Byte stream vs Packet service: over kill Connection delays: 3 RTT for secure TCP Slow Start: under utilization of the link capacity Leads to new not TCP based media transport work, QUIC, WebRTC Z. Li, Multimedia Communciation, 2018 p.33

34 Outline ReCap Lecture 17 Congestion Models and Control TCP and TCP Friendly Congestion Model New Congestion Work at RMCAT Summary Z. Li, Multimedia Communciation, 2018 p.34

35 WebRTC Motivation: native browser support for real time communication for a variety of applications > Javascript API for HTML (W3C) > Signalling & NAT traversal (IETF RTCWEB) > Security (IETF RTCWEB) > Congestion control (IETF RMCAT) Z. Li, Multimedia Communciation, 2018 p.35

36 RMCAT RMCAT = RTP Media Congestion Avoidance Techniques IETF working group resources Main RMCAT technology Google's congestion control (GCC) o L. De Cicco et al.: Experimental Investigation of the Google Congestion Control for Real- Time Flows. o V. Singh et al.: Performance Analysis of Receive-Side Real-Time Congestion Control for WebRTC. o L. De Cicco et al.: Understanding the Dynamic Behaviour of the Google Congestion Control NADA (Cisco) X. Zhu, R. Pan: NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Dflow: P. O'Hanlon, K. Carlberg: DFlow: Low latency congestion control Coupled Congestion Control S. Islam et al.: One Control to Rule Them All - Coupled Congestion Control for RTP Media (Poster) Congestion Control and FEC M. Nagy et al.: Congestion Control using FEC for Conversational Multimedia Communication (Nokia may have IPR) Z. Li, Multimedia Communciation, 2018 p.36

37 GCC Google Congestion Control (GCC) implemented in Chrome and Firefox to support WebRTC Utilizes RTP and RTCP for media data transport and control Has sender side control, which is loss based, probe the available BW as sending rate A s. Receiver side control is delay based, computes REMB, Receiver Estimated Maximum Bitrate, A r to limit the sending rate A s Z. Li, Multimedia Communciation, 2018 p.37

38 GCC Sender Side Logic Measure of Loss: f l (t k ) at time t k, where the k-th RTCP message is received, the fraction of packets sent lost TCP Friendly Rate (TFRC) : The sending rate is given by, Hi-loss rate: send at TRFC rate, not like TCP halve the CWnd Small loss rate: AMID like behavior. Mid loss rate: maintain current rate Z. Li, Multimedia Communciation, 2018 p.38

39 GCC Receiver Side Logic Z. Li, Multimedia Communciation, 2018 p.39

40 Receiver Side State Machine Receiver side update A r (t i ) according to the congestion state estimation Dec Hol d Inc Packet Arrival Stats based link usage state estimation, Packet delay variation: Where, {t i } {T i } are time stamps of ith video packet sending and recving time. C is the link capacity, L is the video packet size. Queuing delay variation: m(t i ) = t i t i-1 (T i -T i-1 ) Network jitter noise, n(t i ), Z. Li, Multimedia Communciation, 2018 p.40

41 Link Overuse Detection Observe arrival filter signal m(t): Z. Li, Multimedia Communciation, 2018 p.41

42 Loss Control Use a mix of FEC and ARQ to control losses AL-FEC for erasure/loss control is an active topic area. The good rate, i.e, the sending rate minus FEC and ARQ cost is the true media rate With FEC and ARQ No FEC and ARQ GCC forces r FEC (t) < 0.5 A s (t) GCC ARQ: at most re-transmit A s (t)*rtt bytes of data. (not a good option for live and low delay applications!) Z. Li, Multimedia Communciation, 2018 p.42

43 GCC Simulation Set up Two scenarios L. DeCicco et.al., Packetvideo workshop, 2013 Z. Li, Multimedia Communciation, 2018 p.43

44 GCC Link Capacity Utilization Single Flow Fairly good utilization, throughput follows the link capacity change Z. Li, Multimedia Communciation, 2018 p.44

45 Single GCC Flow Case Z. Li, Multimedia Communciation, 2018 p.45

46 GCC sharing with TCP flow GCC is not getting the fair share of throughput at the bottleneck REMB received Z. Li, Multimedia Communciation, 2018 p.46

47 2 GCC Flows sharing bottleneck Lack of cross traffic coordination, results in unpredictable behavior Z. Li, Multimedia Communciation, 2018 p.47

48 Summary TCP Type Congestion Control Congestion Window Based Slow Start at the start Congestion Avoidance AIMD Under Utlization of the link Slow connection New RMCAT Congestion Control Mix of Delay and Loss based control Sender rate is based on loss Receiver rate is based on delay, variation of packet arrival signal. RTP for data RTCP for signalling Z. Li, Multimedia Communciation, 2018 p.48