review of P2P workloads

This paper studies the p2p file sharing workload to better understand the
behavior of p2p system. They analyze the Kazaa trace collected in Univ. of
Washington. Kazaa is a mixture of workloads. It includes several kinds of
multimedia data, such as video files and audio files.

The authors explore the behavior of peers (users) and the characteristics
of objects. The most important observations are: objects are downloaded
only once, new objects are born, and new clients arrive. The
fetch-at-most-once feature is reasonable in p2p system with multimedia
workload. Because multimedia objects never change, peers tend to download
it only once. Unlike popular web page data, the unchanged popular
multimedia data will be replaced by new objects. New clients arrive and
old clients may leave the system for ever. The dynamic of objects and
clients affects the object popularity in Kazaa trace. The Kazaa trace is
not Zipf-like, because of reasons listed above. This paper proposes a
model of p2p file sharing workloads to prove their conclusion. It also
discussed the impact of locality-awareness in Kazaa trace.

Kazaa trace was collected at the interface between UW and the Internet.
The design and measurement of Kazaa may affect some characteristics of the
workload. For example, some requests issued by peers in UW and received by
other peers in UW were not collected.

For the locality in Kazaa, different workloads may affect the benefit we
can gain from the locality. Since objects are fetched at most once in most
cases, the cache only helps for multiple peers accessing the same object.
In Kazaa, most users are university students who have similar interests,
the overlapping among their requests may be high, as a result, we can have
86% bandwidth save. However, in other organizations, say a company with
employees with ages 20~50, their interests are very different. The
workload of their requests in p2p may have less locality benefits.

The authors study the effect of peer availability to hit rate. It is also
interest to look at object availability in Kazaa. The ratio of successful
request to all requests in Kazaa request trace is bounded by 66% (based on
1000000 requests samples). The possible reason is the failed requests are
requesting for objects that are not exist in either up or down peers. As a
result, this upper bound can not be improved by improving object
availability. The object availability helps in cases such as when a
request is asking for an object which is not available in up peers, but is
available in some down peers. By improving the availability of this kind
of objects, the successful request rate could be improved.
Received on Fri Nov 25 2005 - 21:57:23 EST