ECE 5578 Multimedia Communication Lec 19 - Error and Loss Control Zhu Li Dept of CSEE, UMKC Office: FH560E, Email: lizhu@umkc.edu, Ph: x 2346. http://l.web.umkc.edu/lizhu slides created with WPS Office Linux and EqualX LaTex equation editor Z. Li, Multimedia Communciation, 2018 p.1
Outline ReCap Lecture 18 TCP Congestion Control RMCAT Congestion control work NS-3 Tutorial FEC Digital Fountain Code Summary Z. Li, Multimedia Communciation, 2018 p.2
TCP Congestion Control AIMD- Additive Increase Multiplicative Decrease, congestion window based control. When receiving ACK, increase cwnd by one, when packet loss, halve the cwnd Slow Start (TCP Tahoe): Introducing a threshold control When below thres, double cwnd per ACK If above thres, additive increase If loss, halve thres, cwnd=1 Z. Li, Multimedia Communciation, 2018 p.3
TCP Congestion 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 = cwnd/2 Congwin = 3 + Congwin/2 Each duplicate ACK received Congwin++ After new ACK o Congwin = Threshold o return to congestion avoidance 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.4
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.5
WebRTC Motivation: native browser support for real time communication for a variety of applications Non TCP based connectivity, over RTP instead. Javascript API for HTML (W3C) Signalling & NAT traversal, Security (IETF RTCWEB) Congestion control (IETF RMCAT) Z. Li, Multimedia Communciation, 2018 p.6
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.7
Receiver Side State Machine Receiver side update A r (t i ) according to the congestion state estimation 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.8
Link Overuse Detection Observe arrival filter signal m(t): Z. Li, Multimedia Communciation, 2018 p.9
GCC Link Capacity Utilization Single Flow Fairly good utilization, throughput follows the link capacity change Z. Li, Multimedia Communciation, 2018 p.10
Outline ReCap Lecture 18 TCP Congestion Control RMCAT Congestion control work NS-3 Tutorial FEC Digital Fountain Code Summary Z. Li, Multimedia Communciation, 2018 p.11
Loss Recovery: ARQ vs FEC When a packet did not reach the destination the receiver sends back a requests for retransmission Alternatively, the receiver can send back acknowledgement messages for each successfully received packet. The sender keeps track of the missing packets and retransmits them until all have been acknowledged This does NOT scale in multicasting situation Z. Li, Multimedia Communciation, 2018 p.12
Multicasting Over Erasure Channel Examples File Downloading P2P sharing Broadcasting Z. Li, Multimedia Communciation, 2018 p.13
Use Cases Reliable multicast Parallel downloads Long-distance transmission (avoiding TCP) One-to-many TCP Content distribution on overlay networks Streaming video ARQ is too late. Z. Li, Multimedia Communciation, 2018 p.14
The Binary Erasure Channel 0 1 1-a a a 1-a 0 e 1 e erasure a erasure probability Erasure channel Capacity: C= 1-a Intuitive interpretation: since a proportion a of the bits are lost in the channel, we can recover (at most) a proportion (1-a) of the bits. Z. Li, Multimedia Communciation, 2018 p.15
Challenges The erasure probabilities are unknown. Want to come arbitrarily close to capacity on each of the erasure channels, with minimum amount of feedback. Traditional codes don t work in this setting since their rate is fixed. Need codes that can adapt automatically to the erasure rate of the channel. Z. Li, Multimedia Communciation, 2018 p.16
Broadcast channel with erasures On a broadcast channel with erasures, the repetition schemes are very inefficient, and can lead to network congestion An appropriate Forward Error Correction (FEC) Code should achieve the theoretic channel capacity without feedback channel With classical codes the design of the fixed rate R=K/N, should be performed to worst case conditions This restriction makes this coding inefficient also Z. Li, Multimedia Communciation, 2018 p.17
Reed-Solomon Code An (N,K) Reed-Solomon code correctly decode the K symbols of the message from K codeword symbols However, Reed-Solomon codes are only useful for small values of N and K The coding / decoding cost is of order K( N - K)log2 N Z. Li, Multimedia Communciation, 2018 p.18
Digital Fountain Codes If the error probability of a BEC varies, the ideal code should allow on the fly variable encoding rate R=K/N With Reed-Solomon codes it is not possible to change R on the fly Digital Fountain Codes Original content Encoded packets Users reconstruct Original content as soon as they receive enough packets Encoding Engine Transmission Z. Li, Multimedia Communciation, 2018 p.19
Digital Fountain Code Fountain Code Properties Sender sends a potentially limitless stream of encoded bits. Receivers collect bits until they are reasonably sure that they can recover the content from the received bits, and send STOP feedback to sender. Automatic adaptation: Receivers with larger loss rate need longer to receive the required information. Want that each receiver is able to recover from the minimum possible amount of received data, and do this efficiently. Z. Li, Multimedia Communciation, 2018 p.20
Credit: Amin Shokrollahi, EPFL Content Enc Digital 21 buckets
Fountain Codes Distribution on 22
Universality and Efficiency [Universality] Want sequences of Fountain Codes for which the overhead is arbitrarily small [Efficiency] Want per-symbol-encoding to run in close to constant time, and decoding to run in time linear in number of output symbols. 23
LT-Codes Invented by Michael Luby in 1998. First class of universal and almost efficient Fountain Codes Output distribution has a very simple form Encoding and decoding are very simple 24
LT-Codes 25
The Fountain Coding Process Input symbols Choose 2 Random original symbols XOR 2 Choose weight Insert header, and send Weight Weight table Prob 1 0.055 2 3 4 0.3 0.1 0.08 26 100000 0.0004
Decoding 27
Decoding 28
Decoding 29
Decoding 30
Decoding 31
Decoding 32
Decoding 33
Decoding 34
Decoding 35
The Degree Distribution Each codeword is a linear combination of d symbols from the message m The degree d is chosen at random from a degree distribution (d) There are two design conflicts: The degree of some codewords should be high to guarantee that all the message symbols are covered The degree of some codewords should be low in order to start the decoding process and keep going Z. Li, Multimedia Communciation, 2018 p.36
Soliton distribution Can we design a degree distribution that guarantees the optimal Shannon limit of decoding the K symbols of the message after K received codewords? We want a distribution that on average guarantees that just one message symbol is uncovered at each iteration, i.e, only one symbol is having degree one connection to the fountain bits Such a distribution is the Soliton Z. Li, Multimedia Communciation, 2018 p.37
Soliton distribution Step 0 The expected number of codeword symbols of degree one at step zero should be 1, otherwise no way to start decoding Step 1 One of the message symbols is decoded and it lower the degree of some of the codeword symbols. At the end of step 1, at most one degree 2 codeword should be connected to the decoded message symbol in order to decrease its degree to one and the process continues... Step k Continue the process checking at each step that one of the codeword symbols has degree one Z. Li, Multimedia Communciation, 2018 p.38
Ideal Soliton Distribution The mean degree of this distribution is þ ý ü î í ì - = = - = = 1) ( 1,, 12 1, 6 1, 2 1, 1, 2,3, for 1) ( 1 1/ 1 K K K K d d d K d d K d d e K d K d d log 1 1 1 1 å å = =» - = = Z. Li, Multimedia Communciation, 2018 p.39
Soliton distribution c 0 c 1 c 2 c K codewords m 0 m 1 m 2 m K Message symbols With the Soliton distribution the expected number of edges from each message symbol will be log e K Z. Li, Multimedia Communciation, 2018 p.40
Soliton distribution c 0 c 1 c 2 c K codewords m 0 m 1 m 2 m K Message symbols The decoding of m 0 from c 0 causes the degree of the connected codewords to decrease by 1 Z. Li, Multimedia Communciation, 2018 p.41
Robust Soliton Distribution Z. Li, Multimedia Communciation, 2018 p.42
Performance with Robust Soliton Degree Distribution S c loge ( K / d ) K = K K Z. Li, Multimedia Communciation, 2018 p.43
Ideal Soliton Distribution Performance Percent of decoded x 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 Soliton with K= 1000 and N= 1500 Experimental (1-d) 0 0 50 100 150 200 250 300 Test number Z. Li, Multimedia Communciation, 2018 p.44
Robust Soliton Distribution Online with K= 1000 and N= 1500 = 0.5 d= 0.05 1 Experimental (1-d) 0.99 Percent of decoded x 0.98 0.97 0.96 0.95 0.94 0 50 100 150 200 250 300 Test number Z. Li, Multimedia Communciation, 2018 p.45
Raptor Code A development of LT code by introducing a pre-coding group to have desirable # of redundant symbols for efficient LT code implementation Proper ratio of source symbols vs desired number of fountain symbols can leads to better performance. Ref: A. Shokrollahi, Raptor Codes, IEEE Trans on Info Theory, vol. 52(6), June 2006. Z. Li, Multimedia Communciation, 2018 p.46
Application of Digital Fountain Code Broadcast MBMS in LTE networks Uses Raptor Code (RFC5053): https://tools.ietf.org/html/rfc5053 Use a LDPC precode before LT coding Linear complexity guarantee Adopted for the MBMS and embms systems we use, e.g, pushing the APP updates to users by carriers DVB-H Broadcast system RS and Raptor codes. Ref: http://www.etsi.org/deliver/etsi_tr/102900_102999/102993/01.01.01_6 0/tr_102993v010101p.pdf Open Source Raptor Project: Opensource RaptorQ (RFC6330) http://openrq-team.github.io/openrq/ Z. Li, Multimedia Communciation, 2018 p.47
FEC Summary One very useful technique for error and loss recovery APP layer forward erasure correction (AL-FEC): Early days: Reed-Solomon code Fountain Codes: LT code, Raptor, and Raptor Q Key features of Fountain Codes Rateless FEC: you don t need to fix the coding ratio Suitable for multicasting Suitable for when ARQ is not feasible/economical Z. Li, Multimedia Communciation, 2018 p.48