1 / 15

UFFT: Ultra-Fast File Transfer

UFFT: Ultra-Fast File Transfer. Sandeep Kakumanu Cheng-Lin Tsao Muhammad Raza Khan. Background. Current bulk file transfer Either single path from single server Or multiple paths from multiple servers (one from each) in a costly CDN Multi-path routing

Download Presentation

UFFT: Ultra-Fast File Transfer

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. UFFT: Ultra-Fast File Transfer Sandeep Kakumanu Cheng-Lin Tsao Muhammad Raza Khan

  2. Background • Current bulk file transfer • Either single path from single server • Or multiple paths from multiple servers (one from each) in a costly CDN • Multi-path routing • Existence of multiple paths from single server to single client • Potential benefits: increased end-to-end throughput, loss/failure tolerance Source 2 Source Client Paths Data Streams Source 3

  3. Proposed architecture • Multi-path routing using overlay networks • One direct path from server to client • Multiple indirect paths through overlay nodes Client Source Direct path Indirect paths

  4. Our solution • Use overlay networks to setup multiple paths • Use digital fountain codes to minimize probing • Fountain codes: a class of rateless codes • Generate huge number of encoded packets • Decode from any subset of K encoded packets • Inherent functionality of integrating traffic

  5. Milestones • Finished implementing 3 different rateless codes in C++ • # symbols K = 10000, size of symbol = 1000 bytes • Random codes: high decoding complexity O(K3) • LT codes: O(K) complexity, 2 seconds • Online codes: also O(K) • Implement overlay network on PlanetLab • Send encoded packets over multiple paths on the overlay • Performance measurements

  6. Original symbols LT codes (encoding) Original data Degree distribution (k=10000,c=0.03,δ=0.01) Choose degree Select symbols XOR encoding Random generation Random seed Header Encoded symbol

  7. LT codes (decoding) Original data Original symbols Encoded symbols Encoded symbols

  8. Measurements

  9. Improvements in LT Codes • LT Codes on the average require 500 more encoded blocks then the original number of blocks • Can we some how reduce this upper bound? • Online Codes

  10. Original symbols Online Codes Original data ε = sub-optimality Q= success probability F= Function(ε) Step 1 2 … Q 1 XOR encoding Aux symbols Step 2 Composite symbols X X X Step3 Step4 Choose degree Select symbols XOR encoding Step5 Random generation Step6 Random seed Header Encoded symbol

  11. Online Codes (Decoding) Original data Aux symbols Original symbols X X X Arrows indicate decoding from Aux blocks Encoded symbols No of Encoded Blocks needed to decode a file of Blocks n = (1+ 3*ε )n

  12. Decoded Blocks vs Received Blocks

  13. Overhead of Online Codes Encoding

  14. Conclusions • Diversity of multi-path was exploited to increase capacity • Digital fountain codes are used to prevent adverse effects of blasting packets • Implemented 2 different Digital fountain codes in C++ • Digital Fountain Codes can be used as Poor Man solution for transmitting data on multiple paths. Instead of first analyzing different paths just encode data using Digital Fountain Codes and send.

  15. Issues and Future Work • Issues • Computation overhead • Not suitable for slow machines • Inconsistent data transfer • Difference in file system? • Future work • Complete implementation • Control mechanism • Segmentation into blocks • Offline processing • Primary thread: decoding decision, secondary thread: XOR • Reserve network resources • Rate control • No rate control in this project • Not TCP-friendly

More Related