RPT: Re-architecting Loss Protection for Content-Aware Networks

Transcription

1 RPT: Re-architecting Loss Protection for Content-Aware Networks Dongsu Han, Ashok Anand ǂ, Aditya Akella ǂ, and Srinivasan Seshan Carnegie Mellon University ǂ University of Wisconsin-Madison

2 Motivation: Delay-sensitive communication Soft-realtime intra-data center communication [DCTCP, D 3 ] Response time ~250ms Real-time streams: FaceTime, Skype, on-line games. Maximum one way latency ~150ms Time critical interdata center communication [Maelstrom] Minimizing data loss in time-critical communication is important, but challenging because of the time constraint. 2

3 Loss protection today: Redundancy-based recovery Forward Error Correction Delay Bandwidth for robustness Redundant packets (n-k) Original packets (k) FEC couples delay with redundancy Small batch size makes FEC more susceptible to bursty loss Difficult to tune parameters (n and k) [TIP2001,INFOCOM2010] Amount of redundancy 20%~50% in Skype video[multimedia 09] 3

4 Content-aware networks changes the trade-off of redundancy Content-aware networks = caching + contentaware processing to remove duplicates Caching effectively minimizes the bandwidth cost of redundancy RE cache RE cache Examples Redundancy elimination (RE) [SIGCOMM 08] Bandwidth overhead of 100% redundancy: 3% Content-Centric Networking (CCN) [CoNEXT 09] 4

5 Product: WAN optimizers (10+ vendors) Cisco, Riverbed, Juniper, Blue Coat Systems E.g., Cisco deployed RE on 200+ remote offices. Corporate networks Deployment of content-aware networks Riverbed: 50+ corporate customers, datacenter deployments Isolation from Cross traffic Main office WAN optimizer VPN ( Virtual wire ) WAN optimizer Branch 5

6 redundant Redundant Packet Transmission (RPT) RPT Introduce redundancy in a way that the network understands RE Network Redundancy Elimination Router FEC Questions/Challenges How do we make sure we retain the robustness benefits? How much redundancy is needed? How does it compare with FEC? Is this safe to use? 6

7 Redundant Packet Transmission (RPT) RPT Introduce redundancy in a way that the network understands RE Network FEC Redundancy Elimination Router Questions/Challenges How do we make sure we retain the robustness benefits? How much redundancy is needed? How does it compare with FEC? Is this safe to use? 7

8 RPT on Redundancy Elimination (RE) Networks RE cache holds packets received during the past ~10 secs Loss model: Congestive packet loss that happens inside a router. Decompressed packet Compressed (deduplicated) packet Packets RE Decode RE Encode Low overhead A A A RE cache Queue RE cache Robustness Incoming interfaces Redundancy Elimination Router Outgoing interfaces 8

9 Redundant Packet Transmission Introduce redundancy in a way that the network understands Redundant Transmission RE Networks 9

10 Redundant Packet Transmission Introduce redundancy in a way that the network understands Benefits: RE Networks Retain the robustness benefits of redundancy Minimize the bandwidth cost Application can signal the importance of data. (Fine-grained control) 10

11 A Case Study of RPT Redundant Packet Transmission (RPT) - Send multiple copy of the same packet. - Send every packet r times. - Applied to live video in RE networks. Redundant Packets Transmission Hop-by-hop RE networks Partially content-aware networks SmartRE networks Networks with link-layer loss Content Centric Networks (CCN) Time-critical communication 11

12 Fraction of Overhead Analytical Comparison with FEC 0.50 FEC(10,5) 2% random loss. p = 0.02 FEC(n=10,k=8) Batch size (n=10) Delay 0.40 FEC(10,6) 0.30 FEC(10,7) RPT(4) RPT(3) RPT(2) 1E-7 1E-6 1E-5 1E-4 1E-3 1E-2 1E-1 1E+0 1E+1 End-to-end data loss rate (%) FEC(10,8) FEC(10,9) Naive Naive 2% data loss 0 overhead Coded redundancy RPT(3) Original pkts (k=8) Delay Redundancy (r=3) 12

13 Fraction of Overhead Analytical Comparison with FEC % random loss. p = 0.02 FEC(10,5) Naive FEC(20,k) FEC(10,6) FEC(10,k) FEC(100,k) RPT(r) FEC(20,14) FEC(10,7) FEC(20,16) FEC(10,8) FEC(100,90) FEC(10,9) RPT(4) RPT(3) RPT(2) 1E-7 1E-6 1E-5 1E-4 1E-3 1E-2 1E-1 1E+0 1E+1 End-to-end Data loss rate (%) FEC(n=20,k=16) Delay Batch size (n=20) Original pkts (k=16) 13

14 Fraction of Overhead Analytical Comparison with FEC % random loss. p = 0.02 FEC(10,5) Naive FEC(20,k) FEC(10,6) FEC(10,k) FEC(100,k) RPT(r) FEC(20,14) FEC(10,7) FEC(20,16) FEC(10,8) FEC(100,90) FEC(10,9) RPT(4) RPT(3) RPT(2) 1E-7 1E-6 1E-5 1E-4 1E-3 1E-2 1E-1 1E+0 1E+1 End-to-end Data loss rate (%) Scheme FEC(10,7) FEC(20,16) FEC(100,92) RPT(r) Max Delay@ 1Mbps 168 ms 300 ms 1300 ms Tunable Skype video call 128~300kbps Skype (HD) 1.2~1.5Mbps 14

15 Experimental Evaluation Thorough evaluation on 3 different aspects of RPT End user performance Ease of use (parameter selection) Impact on other traffic Methodology Real experiment Trace based experiment Simulation CIF: 352x288 15

16 Video Source Realistic Cross traffic Sink Evaluation Framework RE router implementation (Click, NS2) Video quality evaluation using evalvid Sender Network Receiver FEC FEC encoder (n,k) Measure BW overhead RPT(r,d) RE encoder (RE) RE decoder RE RPT Measure loss rate, video quality (PSNR) 16

17 Average PSNR (db) E2E Performance: Video Quality Encoded video at sender (Before loss) RPT FEC 17

18 Average PSNR (db) E2E Performance: Video Quality Encoded video at sender Received video Packet loss rate ~2% RPT FEC 18

19 E2E Performance: Video Quality RPT(3) Overhead ~6% FEC(10,9) Overhead ~10% Naïve UDP 1.8dB ~ 3dB difference in quality 19

20 Fraction of Overhead 0.4 FEC(10,6) E2E Performance: overhead and robustness Packet loss rate ~2% Naive FEC(10,7) FEC(10,8) FEC(10,k) RS(r) RPT(r) 0.1 FEC(10,9) RPT(4) RPT(3) RPT(2) 0 1E-04 1E-03 1E-02 1E-01 1E+00 1E+01 End-to-end Data Loss Rate (%) Naive 20

21 Impact on other traffic RPT flows get prioritized. Packet loss rate : 9%. Other Flows Loss Sender (Before loss) Receiver (Non-RPT) (After loss) 9% loss RPT Flows Receiver (RPT) (After loss) Original Redundancy Bandwidth use (Mbps) Throughput reduction: 2% Loss 21

22 Is flow prioritization a problem? Not a problem: Important flows should be prioritized. Problem: Unfair bandwidth allocation TCP throughput : 18Mbps TCP throughput: 12Mbps How do provide fairness and robustness at the same time? Core problem: RPT flows are not reacting to congestion. Apply TCP-friendly rate control to RPT. Challenge: correctly accounting for possible changes in loss pattern 22

23 Other results in the paper Demonstration of RPT in a real-world setting E.g., Emulated corporate VPN scenario Trace-based experimental results Detailed parameter sensitivity study Network safety (impact on the network) Design and evaluation of TCP-friendly RPT Strategies on other content-aware networks 23

24 UEP Generalized RPT Many sophisticated schemes are enabled by FEC. Priority encoding transmission (PET), unequal error protection (UEP), multiple description coding (MDC) Prioritization within a flow for graceful degradation of quality Redundancy elimination networks [SIGCOMM 08] P-frame I-frame PET/MDC Very important: Sent x3 (byte-level redundancy) Important: Sent x2 24

25 Conclusion Key Idea of RPT: Don t hide, expose redundancy! Key Features High robustness, low overhead user performance Ease of use: parameter selection, per-packet redundancy/delay control Flow prioritization Applicability Applies to delay-sensitive communications in contentaware networks in general. 25

26 26