1 / 21

Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads

Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads. John Byers, Boston University Michael Luby, Digital Fountain, Inc. Michael Mitzenmacher, Harvard INFOCOM 99. Multicast: to save bandwidth. Parallel download: to improve speed.

felicia-munoz
Download Presentation

Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Accessing Multiple Mirror Sites in Parallel:Using Tornado Codes to Speed Up Downloads John Byers, Boston University Michael Luby, Digital Fountain, Inc. Michael Mitzenmacher, Harvard INFOCOM 99

  2. Multicast: to save bandwidth. Parallel download: to improve speed. The Problem Sender Senders Receiver Receivers

  3. Many-to-many Distribution Senders • Heterogeneous environment of senders and receivers. • Senders broadcast. • Receivers gather data as fast as possible from as many sources as possible. Receivers

  4. Results • A simple, robust, scalable solution for parallel downloads and many-to-many distribution using Forward Error Correction. • Examination of tradeoffs • Speed vs. Goodput

  5. Applications • Internet • Connect to many mirror sites simultaneously. • Multiple access media • ISDN and modem simultaneously. • Mobile clients • Multiple access points. • Listen to multiple frequencies. • Satellite networks • Ground user receives from many satellites.

  6. 1 1 2 1 2 2 2 1 Assumptions • Possible to create bottleneck-disjoint paths. • Otherwise wasted bandwidth, more congestion. • Receiver should not be the bottleneck. • For people with big pipes. Senders Senders Shared Bottleneck Bottleneck Disjoint dropped Receiver Receiver

  7. Solutions without Coding • A protocol without codes: • Initially receiver tells each of s senders to send disjoint 1/s parts of the file. • If one sender finishes early, re-negotiate packets to be sent. • Continue until all packets arrive. • Problems • Significant feedback. • Unsuitable for many-to-many. • Complexity. • No protection against losses. • Wait for last packet.

  8. Forward Error Correction (FEC) • Message of n packets encoded as cnpackets. • A receiver decodes once enough packets arrive. • FEC codes improve multicast scalability • Encoding packets can correct different losses for different receivers. • Reduces feedback, to even feedback-free solutions.

  9. Tornado Codes • Tornado Codes are FEC codes that are • Very fast (linear time). • Better for large files. • Information-theoretically slightly suboptimal. Requires 1.055n packets to decode n packet message.

  10. Ideal Solution: Digital Fountain • Reconstruct file from anyn packets, from any source. • Feedback free: no need for receivers to acknowledge specific packets. • Fountain metaphor: drink when the cup is full. • Approximate digital fountain solution using Tornado codes. • Reception inefficiency due to overhead of Tornado codes, duplicate packets.

  11. Feedback Free Solution Original Message • Senders encode message the same way. • Senders cycle through permutation of encoding • When receiver obtain any 211 distinct packets, it can decode to obtain the message. 1 - 200 Encoded Message 1 - 600 17 485 23812 311 411 512... 216 156 7 128 415 238 333... 397 188 25 315 275 499 12...

  12. Performance Metrics • Speedup: • Stretch factor (c): message of n packets encoded as cn packets. • Reception inefficiency (z): zn packets arrive before decoding. • Code overhead • Duplicates Download time now Download time using single fastest sender

  13. Tradeoffs • Increasing stretch c: • Lessens duplicates: senders have more packets to send, so random collisions less likely • Increases encoding/decoding time, memory requirements, and complexity. (Grow linearly in c.) 17 485 23812 311 411 512... 216 156 7 128 415 238 333... 397 188 25 315 275 499 12...

  14. 1 2 4 3 5 1 3 5 2 1 4 3 4 5 3 1 2 4 Feedback Free Solution • Pros • Simple • Loss protection • Good download speedups • No feedback, coordination • Solves many-to-many • Cons • Extra bandwidth for Tornado codes (5.5%) • Extra bandwidth from packet duplicates • depends on c, number of senders, variation in rates • additional 5-25+ %

  15. 2 7 6 3 9 1 2 7 6 3 9 1 2 7 6 3 9 1 Rare Feedback • Senders use same permutation of encoding. • Receivers tell each of s senders to send 1/s of the encoding. • If c>s, each sender has 1 file worth of data. • In rare cases, re-negotiate, or have senders send the rest in random order.

  16. 2 7 6 3 9 1 2 7 6 3 9 1 7 6 3 9 1 2 Rare Feedback • Pros • Simple • Loss protection • Rare feedback, minimal coordination • Extra bandwidth for Tornado codes only • Cons • Does not solve multi-multi • Extra bandwidth for Tornado Codes

  17. Conclusions • Fast parallel download and many-to-many distributions are practical. • Trade goodput for speed. • FEC improves protocols. • Simpler. • Less feedback. • Loss protection. • Deployment issues (fairness, bottleneck disjoint paths) still open.

More Related