Comments on: P4P: smart, fast and easy P2P http://storagemojo.com/2008/03/16/p4p-smart-fast-and-easy-p2p/ Data storage info & analysis Tue, 20 May 2008 19:14:28 +0000 http://wordpress.org/?v=2.5.1 By: Paul http://storagemojo.com/2008/03/16/p4p-smart-fast-and-easy-p2p/#comment-181496 Paul Tue, 18 Mar 2008 01:21:28 +0000 http://storagemojo.com/2008/03/16/p4p-smart-fast-and-easy-p2p/#comment-181496 Ars Technica links to one paper (tech enough to have equations, at least): http://www.dcia.info/documents/P4P_Overview.pdf Ars Technica links to one paper (tech enough to have equations, at least):

http://www.dcia.info/documents/P4P_Overview.pdf

]]> By: Jeff Darcy http://storagemojo.com/2008/03/16/p4p-smart-fast-and-easy-p2p/#comment-181234 Jeff Darcy Mon, 17 Mar 2008 10:55:33 +0000 http://storagemojo.com/2008/03/16/p4p-smart-fast-and-easy-p2p/#comment-181234 This is not too dissimilar from what I was doing for the second half of my tenure at EMC. On the one hand P4P is more fully distributed, on the other it lacks support for writes with full coherency and authentication, but those are all kind of beside the point. What matters is that the idea of setting up a dynamic tree/graph/whatever based on the actual network topology and then propagating data through that network instead of between peers at random really can produce dramatic efficiency gains. In one of my specs, which IIRC got reproduced almost verbatim in the associated patent, I refer to the two cardinal laws of data distribution: * Never transmit data over the same link multiple times when once could have sufficed. * Never transmit data over a link once when zero could have sufficed. Most systems tend to violate one rule or the other, most often the first - and since infinity minus one is greater than one minus zero that can be far worse. Because of my work I was involved with some mostly-academic projects in or near the P2P space at the time. There was a distinct pattern of starting out with DHTs and such that completely ignore network topology, then trying to bolt on some limited form of topology awareness later as latency (and sometimes reliability but rarely bandwidth) turned out to be a problem after all. Few had the foresight to take topology into account right at the start. What I really wonder about in P4P is how - and how well - the nodes cooperate wrt placement of data copies. On the one hand, it can be good to have one piece of data replicated as many places as possible. On the other, it can be good to replicate as many pieces of data as possible. Total storage space being finite even in a P2P network, balancing these needs is a much-studied problem and I'm curious what approach the P4P team took. This is not too dissimilar from what I was doing for the second half of my tenure at EMC. On the one hand P4P is more fully distributed, on the other it lacks support for writes with full coherency and authentication, but those are all kind of beside the point. What matters is that the idea of setting up a dynamic tree/graph/whatever based on the actual network topology and then propagating data through that network instead of between peers at random really can produce dramatic efficiency gains. In one of my specs, which IIRC got reproduced almost verbatim in the associated patent, I refer to the two cardinal laws of data distribution:

* Never transmit data over the same link multiple times when once could have sufficed.

* Never transmit data over a link once when zero could have sufficed.

Most systems tend to violate one rule or the other, most often the first - and since infinity minus one is greater than one minus zero that can be far worse. Because of my work I was involved with some mostly-academic projects in or near the P2P space at the time. There was a distinct pattern of starting out with DHTs and such that completely ignore network topology, then trying to bolt on some limited form of topology awareness later as latency (and sometimes reliability but rarely bandwidth) turned out to be a problem after all. Few had the foresight to take topology into account right at the start.

What I really wonder about in P4P is how - and how well - the nodes cooperate wrt placement of data copies. On the one hand, it can be good to have one piece of data replicated as many places as possible. On the other, it can be good to replicate as many pieces of data as possible. Total storage space being finite even in a P2P network, balancing these needs is a much-studied problem and I’m curious what approach the P4P team took.

]]>