Lec 19 Error and Loss Control I: FEC

Transcription

1 Multimedia Communication Lec 19 Error and Loss Control I: FEC Zhu Li Course Web: Z. Li, Multimedia Communciation, Spring 2017 p.1

2 Outline ReCap Lecture 18 TCP Congestion Control RMCAT Congestion control work NS-3 Tutorial FEC Digital Fountain Code Summary Z. Li, Multimedia Communciation, Spring 2017 p.2

3 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, Spring 2017 p.3

4 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 Retransmit packet 3 Sender Receiver ACK 1 ACK 2 ACK 2 ACK 2 ACK 2 ACK 6 Z. Li, Multimedia Communciation, Spring 2017 p.4

5 TCP Throughput TCP Rate at steady state Segment size: MSS Round Trip Delay: RTT Prob of packet loss: p R TCP = MSS RTT 2p p 8 p(1 + 32p2 ) 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, Spring 2017 p.5

6 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, Spring 2017 p.6

7 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 A s t k max X t k, A s t k f l t k, if f l t k > 0.1 = 1.05(A s t k 1 + 1kbps, if f l t k < 0.02 A s t k 1, if 0.02 f l t k 0.1 Z. Li, Multimedia Communciation, Spring 2017 p.7

8 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, Spring 2017 p.8

9 Link Overuse Detection Observe arrival filter signal m(t): Z. Li, Multimedia Communciation, Spring 2017 p.9

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

11 Outline ReCap Lecture 18 TCP Congestion Control RMCAT Congestion control work NS-3 Tutorial FEC Digital Fountain Code Summary Z. Li, Multimedia Communciation, Spring 2017 p.11

12 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, Spring 2017 p.12

13 Multicasting Over Erasure Channel Examples File Downloading P2P sharing Broadcasting Z. Li, Multimedia Communciation, Spring 2017 p.13

14 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, Spring 2017 p.14

15 The Binary Erasure Channel 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, Spring 2017 p.15

16 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, Spring 2017 p.16

17 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, Spring 2017 p.17

18 Polynomial Code Polynomial code of (n, k, n-k+1) A (n, k, 2s +1) code: k 2s Can detect 2s errors Can correct s errors Generally can correct a erasures and b errors if a + 2b 2s n Z. Li, Multimedia Communciation, Spring 2017 p.18

19 Hamming and Reed-Solomon Code An (N,K, N-k+1) Reed-Solomon code correctly decode the K symbols of the message from N 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)log 2 N code bits check bits RS (255, 253, 3) Hamming (2 11-1, , 3) Z. Li, Multimedia Communciation, Spring 2017 p.19

20 Encoding Engine Digital Fountain Codes Transmission 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 Z. Li, Multimedia Communciation, Spring 2017 p.20

21 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, Spring 2017 p.21

22 Credit: Amin Shokrollahi, EPFL Content Enc Digital 22 buckets

23 Fountain Codes Distribution on 23

24 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. 24

25 LT-Codes 26

26 The Fountain Coding Process Input symbols Choose 2 Random original symbols XOR 2 Choose weight Insert header, and send Weight Weight table Prob

27 Decoding 28

28 Decoding 29

29 Decoding 30

30 Decoding 31

31 Decoding 32

32 Decoding 33

33 Decoding 34

34 Decoding 35

35 Decoding 36

36 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 r(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, Spring 2017 p.37

37 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, Spring 2017 p.38

38 Soliton distribution Step 0 The expected number of code word 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, Spring 2017 p.39

39 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 r r r K d d e K d K d d log r r Z. Li, Multimedia Communciation, Spring 2017 p.40

40 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, Spring 2017 p.41

41 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, Spring 2017 p.42

42 Robust Soliton Distribution However, in practice Ideal Soliton Distribution works poorly, due to: At decoding stages, some times no degree 1 symbol correction bits received, and decoding stuck Some symbols not covered at all. Instead, introducing Robust Soliton Distribution Parameter δ, the prob bound on which the decoding fails after receiving certain amount of packets, Constant c=1, or slightly lower than 1, Expected degree: Robust Soliton Distribution, μ d Z. Li, Multimedia Communciation, Spring 2017 p.43

43 Performance with Robust Soliton Degree Distribution Now the expected number of degree one codeword symbols at each step, instead of 1/K, is, With receiving S c log e ( K / ) K K K Checks, the prob of correctly decoding K symbols is (1-δ), for proper parameter of c. Z. Li, Multimedia Communciation, Spring 2017 p.44

44 Ideal Soliton Distribution Performance Soliton with K= 1000 and N= Experimental 0.9 (1- ) 0.8 Percent of decoded x Test number Z. Li, Multimedia Communciation, Spring 2017 p.45

45 Robust Soliton Distribution Online with K= 1000 and N= 1500 = 0.5 = Experimental (1- ) 0.99 Percent of decoded x Test number Z. Li, Multimedia Communciation, Spring 2017 p.46

46 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 Z. Li, Multimedia Communciation, Spring 2017 p.47

47 Application of Digital Fountain Code Broadcast MBMS in LTE networks Uses Raptor Code (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: 0/tr_102993v010101p.pdf Open Source Raptor Project: Opensource RaptorQ (RFC6330) Z. Li, Multimedia Communciation, Spring 2017 p.48

48 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, Spring 2017 p.49