1 / 8

A Swarming Architecture is Good for Internet Data Transfer ?

A Swarming Architecture is Good for Internet Data Transfer ?. Offensed by Jiazhen Chen & Alexander Kiaie. Question1 Why we need this?. The Goal of your proposal is: Use Swarm for Universal Data Transfer It is Better Because? Robust Multipoint-to-point transport layer

callie
Download Presentation

A Swarming Architecture is Good for Internet Data 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. A Swarming Architecture is Good for Internet Data Transfer ? Offensed by Jiazhen Chen & Alexander Kiaie

  2. Question1 Why we need this? • The Goal of your proposal is: • Use Swarm for Universal Data Transfer • It is Better Because? • Robust • Multipoint-to-point transport layer • Can solve the P2P problem • A “Headache” for Network Administrator • However, what about the other aspects? • Potential Traffic Congestion • Cost of numerous connections among peers • Therefore, your “swarm” does not look like a proper pill for curing the headache.

  3. Let’s continue • Despite your ambitious goals • What is your motivation for this novel design? In other words: • Why we need lots of swarm to replace the current architecture? • Possible Key Benefits: • Post-Popularity: • What about using Google Search + SourceForge (OR) • SkyDrive + MSN Search • If it’s legal, there is no barrier for storage and sharing online. • Block availability: • Why, Why, Why we need to exchange blocks that might never trigger our interest ever???

  4. Here we go • The Comparison over Uswarm and isolated swarms: • You claimed: Uswarm has potential benefit over the other • But you admit that here not account for the selfish behaviour. • Maybe they both perform equally bad : ) • You also admit: It’s over-estimate the improvement in reliability since we did not precisely model the tracking process. • So.. The tracking process is arbitrarily defined and simulated? • The impact of DHT, Replicated Trackers on tracker availability • It might be true - experiment • BUT, in this proposal, • No explanation on how you measure the result • Thus, the conclusion is doubtable to us.

  5. It’s not over yet • The incentive Strategies • You said the cost is proportional to the number of open connections • What if when two peers are willing to upload blocks but do not have blocks of interest to the other? • The TCP inefficiencies, traffic shaping might be the cause of the low utilization of bandwidth in practice, not mainly caused by your focus problem. • Without a long-term wide-covered test, it is hard to estimate whether your proposal can really work better than the current architecture.

  6. Deployment • Massive Replication • Knowledge of routing topology • Difficulty • Peer knowledge • Limit free-riding?

  7. Other Work • DHT • Beehive, CoDoNS • They work and have great properties

  8. Plan of Work • 1 Year for analyzing single-swarm behavior? • Security and Privacy testing

More Related