Pick Two Review

High Availability, Scalable Storage, Dynamic Peer Networks: Pick Two
Review
Review by: Troy Ronda

Peer-to-peer networks are often comprised of small-scale hosts with low
availability. The goal of P2P storage, however, is to build large-scale
and highly available storage from them. The argument of this paper is that
an attempt to achieve scalability, storage guarantees, and resilience to
dynamic membership at the same time will overwhelm the available
cross-system bandwidth. This is argued from the fact that members
contribute idle up-stream bandwidth relatively more than idle disk space.
Bandwidth, unfortunately, does not grow as fast as disk storage increases.
The paper discusses a model to evaluate these concerns. This model, in
short, takes issues like downtime vs. departure and needed redundancy into
account when calculating maintenance bandwidth. I will only summarize the
take away points. Short host membership durations will require an enormous
number of hosts to support interesting data scales. This will impact how
fast the total storage in the system can grow. The authors also show that
to achieve 6 nines of availability with 33,000 Gnutella hosts requires
significantly more bandwidth to merely maintain the data than typical
cable modem hosts can provide. The comparison given, is that five
dedicated PCs with a 50 Mbps connection can provide the same service.
Since the numbers do not look good for using home Gnutella users, the
authors also look at admission control. The 5% (~6,000 ) most available
nodes, in Gnutella, provide approximately 40% of the service. The model
shows that adding many (tens of thousands) flaky home users only doubles
total data service over what the 5% best nodes can do by themselves. They
then point out that hardware trends do not suggest that home user
bandwidth will increase enough to compensate for this problem over time.
Another point is that hard drives increase in size much faster than
bandwidth. Hence it becomes harder to share a good fraction of idle disk
space (i.e. The situation is worsening). Another problem is that home
users will have little incentive to contribute bandwidth to data that they
are not interested in. In the end, the scalability problem for these
systems is maintenance bandwidth. Without enormous cross-system bandwidth,
we cannot achieve all three properties at the same time.

The graphs given in this paper strengthen the argument. This is especially
important when reading a paper with many formulae. It is hard to determine
if the model is the right one. I will have to rely on the paper being
accepted as proof. I found the discussion presented in this paper to be
worthwhile. It is good to question the validity of highly available P2P
scalable storage. I liked the emperical analogies to Gnutella to go with
the presented theory. I think it would have been good to discuss how many
nines of availability are appropriate for general P2P storage. I never
found this point in the paper, only that 6 nines do not work.

A major problem after reading this paper is coming up with future work. I
wonder why the authors have argued that six nines of availability is
necessary? Is this the definition of high availability? General P2P
systems are probably not the right strategy to achieve this result,
however many applications might need, for example, 2 nines. Will P2P
storage work for these cases? Should we just give up on P2P storage or is
it appropriate for some applications? The point of erasure coding vs
replication is too subtle in figures 2 and 3. I am not sure why the
authors presented figure 2 only in terms of replication instead of coding.
A factor of eight improvement would not have brought us to the capability
of modem users, but at least it would be much closer. This point is stated
in the text but I argue that many people might have been scared by the
equations, completely missing this point. In the end, I am convinced that
maintenance bandwidth becomes a huge botteneck but mostly from the given
analogies and less from the model presented in the paper.
Received on Mon Nov 14 2005 - 10:50:20 EST