CSC2231 - P2P Workloads review

From: Madalin Mihailescu <madalin_REMOVE_THIS_FROM_EMAIL_FIRST_at_cs.toronto.edu>
Date: Mon, 28 Nov 2005 10:53:29 -0500

Measurement, Modeling and Analysis of a P2P File-Sharing Workload
-----------------------------------------------------------------
K. Gummadi et al.

The paper presents an analysis of a 200-day trace of over 20 TB of Kazaa
P2P traffic. Based on this trace, the authors compare user and object
characteristics in P2P vs the Web. They also propose a validation model
and show the benefits of locality awareness in a P2P architecture.

The paper shows a number of strong results: the fetch at most once rule
existing in a multimedia P2P system (though intuitively this seem clear,
the authors derive this from the trace), the non-zipf behavior of a p2p
workload (though I don't think its only because of the fetch-at-most-once
rule), the important role of new objects in P2P, the importance of locality.
The locality result is actually pretty nice. Despite locality, caching
seems to work great.

I don't think that the difference between the level of patience between
Web and P2P users is that suprising. Failures in Web requests are not
tolerated so well because they are different by nature. If I want to read
the news I want to read them as soon as possible. The same for buying a
book and so on. What I mean is that the Web being an interactive system
and Kazaa a batch-mode one seems pretty obvious.

I guess one of the weaknesses in the trace was not capturing the requests
from university internal peers to other university internal peers. I agree
that substantial untapped locality exists in Kazaa (5.1) but what if the
traffic between university internal peers was significant? Even without
locality in Kazaa, it may happen that X tells Y about n movies that it just
downloaded from an external peer. I know that at a search Kazaa returns a
list of peers to choose from. Y knows X's ID and downloads all n movies
from him internally. This weakness may also affect the other results, like
users slowing down as they age, client activity and even the non-zipf
behavior.
Received on Mon Nov 28 2005 - 10:53:25 EST

This archive was generated by hypermail 2.2.0 : Mon Nov 28 2005 - 10:53:26 EST