Peering-Webphone-Akamai Testbed Scenario

In creating a testbed for our PRC system, we are motivated by current large-scale network traffic scenarios. As previously described, the MP3 file sharing software, Napster [73], and other peering clones such as Gnutella [50] are garnering a great deal of the traffic across many U.S. campuses. A typical MP3 file is on the order of 5 MBs in size. With millions of the files being transfered each day, network traffic jams are being reported almost everywhere this software is used. Simultaneously, we are seeing a large proliferation in cellular phone usage across the country and the world. In the future, a majority of these phones will be web-enabled, adding even a greater load to networks.

To combat network/website overload, Akamai [1], has developed a network of servers around the world to support the adaptive, dynamic replication of content data, allowing data to be placed closer to the requesting user. This technique is called FreeFlow. Here, websites choose content to be served by Akamai using a software utility called Launcher. Launcher will tag objects within a web page that are to be served over the Akamai network. When users request those objects, the Akamai network delivers them from the optimal local server to ensure high-performance and reliability. Akamai's current network of servers numbers over 4000 and spreads across 45 countries.

These trends in both network demand and high-performance network availability pose an interesting large-scale, networking testbed scenario. We call this scenario, Peering-Webphone-Akamai (PWA). This scenario will consist of the following: webphone users requesting stock quotes from the Nasdaq Stock Market, Inc. website, which has been ``Akamaized''. Next, we will configure Gnutella servers that will be available for service at different times throughout a simulated day. The configuration for this scenario will be made as close as possible to the actual by using traffic data collected at universities around the country. Additionally, we will make use of commonly available web and network usage reports, such as [26]. In studying this scenario, our focus will be to understand how these different network traffic usages interact and potentially effect each other in the presence of other background network traffic.

In modeling this scenario, a number of key networking protocols and elements will need to be modeled, including TCP/IP. A critical question is how to effectively model these protocols. Many of these models have been constructed in existing simulation systems, such as Ns [78], and SSFNet [27]. We plan to utilize those existing systems to validate our reverse implementation of protocol models and other network elements.