DHT Selection David Bryan and Henning Schulzrinne DHT

DHT Selection David Bryan and Henning Schulzrinne

DHT Selection • Really 3 questions here – Do we have to choose one, or can we have multiple choices? – If we do multiple choices, do we require a “must implement” for compatibility? – If we have one must implement, how do we select it?

Do we have to choose one? • My thought: No! • Now two very different proposals for protocols that allow modular DHTs – d. SIP supports (has implementations for) Chord and Bamboo -- could add others – P 2 PP is also modular • This generates a protocol requirement that we can negotiate (or at least specify) which one is used

Do we need a “must implement” • Probably • Without it, we can’t ensure different implementations will interoperate • This is where we get into questions

Which one? • What are the requirements for the “must implement” DHT? • Do we want to try to pick a “best for now”? – May not be as things move on anyway • Do we pick a “easy to implement” – Won’t be best now (or later), but may be most interoperable

The current state of DHTs • Chord – [pro] extensive research literature – [con] no large scale deployment • Bamboo/Pastry – [pro] extensive research literature – [pro] Open. DHT – [con] request size cannot exceed UDP MTU • Kademlia – [pro] large-scale deployment (e. Mule) – [con] limited research literature