Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Warding off WAN Gridlock: Page 12 of 21

Does this mean allowing P2P traffic on your network or trying to rate-limit it opens you up to legal liabilities? So far, that's not likely, but check with your institution's lawyers. The Digital Millennium Copyright Act states that a service provider is not liable as long as the provider doesn't have actual knowledge that a material or activity is infringing on copyrights. And, while much P2P traffic is infringing, not all of it is.

At some point, however, content creators may discover an infringing user on your network and issue a notification. If this happens you need to disable or remove the content; failure to act can result in liability. However, this same thing will happen if a user hosts infringing material on an internal Web server as opposed to P2P. Based on precedents at print time, there is no indication that allowing or rate-controlling any particular protocol will open you up to liabilities. Because most content creators are interested in suing the people distributing infringing content--as opposed to users downloading files--several institutions have decided to severely limit or completely block outgoing P2P traffic. Others limit all P2P to just a few kilobits per seconds, thus allowing the traffic but at a rate so slow that nobody wants to use it.

For client machines we used 10 Intel Celeron 500-MHz white box PCs running Microsoft Windows 2000 and an Apple Computer PowerBook G3 connected to the packet shapers at 100 Mbps through an Extreme Summit48 switch, and then to a dual NIC Dell Computer PowerEdge 2450 running Windows 2000 with routing enabled. A T3 (45 Mbps) link was simulated with a Shunra Software's Storm STX-100.

Our server was an Apple Macintosh dual 800-MHz G4 with 1 GB of RAM. We ran FTP, Apache Web server and the Apple Darwin streaming server and used Mercury Interactive's LoadRunner 7.5.1 to generate as many as 100 real TCP sessions. We broadcast "live" a large QuickTime movie set to nonterminating continuous loop. This movie output was, on average, 1.6 Mbps per stream.

LoadRunner let us generate real Windows TCP sessions, and we always ran enough users to oversaturate the T3. Our Web tests included simulating users downloading several multimegabyte pages as well as multiple small pages in succession.

We also tested transferring Web and FTP data simultaneously. We set a policy for a minimum of 20 Kbps per connection with a burst of 50 Kbps, a minimum of 500 Kbps per connection for Web traffic, and 20 Mbps maximum for FTP. We also tested streaming video while concurrently running 100 large Web transfers.

Everybody wants more bandwidth. If you ask your staff if you should install an extra three OC-3s, they'll say yes. When applications become bogged down, one of the first responses is always, "Buy a bigger pipe."