1 / 21

Criticisms of I3

Criticisms of I3. Jack Lange. General Issues. Design Performance Practicality. Limitations. Subscription based model of communication Must know the IDs to subscribe to Must know of at least one I3 server Unreliable service Maybe useful for multicast, anycast, and mobility. Location.

cherid
Télécharger la présentation

Criticisms of I3

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. Criticisms of I3 Jack Lange

  2. General Issues • Design • Performance • Practicality

  3. Limitations • Subscription based model of communication • Must know the IDs to subscribe to • Must know of at least one I3 server • Unreliable service • Maybe useful for multicast, anycast, and mobility

  4. Location • Hash based trigger locations • Random, non-optimal • Triangular routing problem • Solution: use private triggers near by • Requires thorough knowledge of the overlay • Basically, end hosts are responsible for routing

  5. Location/Hashing • They continuously make two conflicting assumptions… • They either use or don’t use hashing whenever it is convenient. • Load balancing • solved by hashing • Triangular routing • solved by choosing optimal I3 node • All the traffic is going through a chosen id

  6. Usability • “Thus, it is important that it not require extensive manual configuration or human intervention.” • “…end-hosts wishing to use i3can locate at least one server using a similar bootstrapping technique; knowledge of a single server is all that’s needed to fully utilize the i3 infrastructure.” • This is misleading • A lot of their features depend on end hosts knowing about the overlay

  7. UDP and TCP • Supposedly I3 should work with unmodified applications • UDP is the only transport mechanism that can use I3. (Section 4.9) • TCP would be broken • Multiple receivers • End host failures aren’t detected • Congestion avoidance and flow control don’t work • End host failures not detected for 15s on average, up to 30s

  8. Security • “…our goal is to design simple and efficient solutions that make i3 not worse and in many cases better than today’s Internet. The solutions outlined in this section should be viewed as a starting point towards more sophisticated and better security solutions that we will develop in the future.” • 2 issues: • It is worse • “that we will develop” – Mentality issue • The mantra of “build it, then make it secure” is naive

  9. Security • Eavesdropping • Mitigated by private(?) ids -- only way to make it secure • BUT: I3 still allows users to receive anything they want, hiding the channel just makes it harder to find • IP does not have eavesdropping capabilities DESIGNED into the system

  10. Security • Denial of Service • Mechanisms to prevent end host flooding • Mechanisms to prevent looping • What about a DOS aimed at a single I3 node? • Does not require loops

  11. Anonymity • Anybody can listen to a common trigger • Back tracing to the sender is then possible • Solutions: • Encryption or trigger chains • Adds overhead • Nobody knows how much…

  12. Performance • So how well is this going to work? • Well, nobody really knows. • They say its only a proof of concept • Carrier pigeons have also been proven to work • And does it even succeed as a proof of concept?

  13. Performance Testbed • “The testbed used for all of our experiments was a cluster of Pentium III 700 MHz machines running Linux. We ran tests on systems of up to 32 nodes, with each node running on its own processor. The nodes communicated over a shared 1 Gbps Ethernet.”

  14. Multicast(?) • “Since we didn’t enable multicast, in our experiments there was never more than one address.” • All they tested was point to point traffic… • Why do we need this for point to point? • Shouldn’t they have at least checked if it worked for the situations they were trying to address?

  15. WAN(?) • “The nodes communicated over a shared 1 Gbps Ethernet.” • Isn’t this supposed to work over the WAN • We see how the overhead effects the system… • At least the overhead they implemented…. • But that’s it • A lot of stuff wasn’t even tested… • Triangular routing problems • Node failures • Trigger chaining • End host routing

  16. Comparison(?) • Absolutely none, but it is just a proof of concept • How well does it work compared to other overlays? • How well does it work compared to just regular IP?

  17. Practicality • “We don’t know what the economic model of would be and whether its most likely deployment would be as a single provider for-profit service (like content distribution networks), or a multiprovider for-profit service (like ISPs), or a cooperatively managed nonprofit infrastructure.” • “…i3 faces significant hurdles before ever being deployed.”

  18. Single Provider • Akamai like service model • Akamai has servers all over the world • Akamai is transparent to the end user • Will the business model support this level of infrastructure?

  19. Multiple Providers • We just saw that BGP is totally kludged together to take into account multiple providers’ policy… • I3 takes all that away

  20. Cooperative non-profit • Might Work • As long as nobody uses it • Somone, somewhere is going to have to pay for it

  21. Present time • So where is it? • Has anyone heard of a service that resembles I3? • Multicast overlay research is still very popular.

More Related