[100352] in North American Network Operators' Group
Re: Can P2P applications learn to play fair on networks?
daemon@ATHENA.MIT.EDU (Joe Provo)
Mon Oct 22 07:01:45 2007
Date: Mon, 22 Oct 2007 06:56:03 -0400
From: Joe Provo <nanog-post@rsuc.gweep.net>
To: nanog@merit.edu
Reply-To: nanog-post@rsuc.gweep.net
In-Reply-To: <83C510C063924E3C92B899EC53158E15@control3>
Errors-To: owner-nanog@merit.edu
On Sun, Oct 21, 2007 at 10:45:49PM -0400, Geo. wrote:
[snip]
> Second, the more people on your network running fileshare network software
> and sharing, the less backbone bandwidth your users are going to use when
> downloading from a fileshare network because those on your network are
> going to supply full bandwidth to them. This means that while your internal
> network may see the traffic your expensive backbone connections won't (at
> least for the download). Blocking the uploading is a stupid idea because
> now all downloading has to come across your backbone connection.
As stated in several previous threads on the topic, the clump
of p2p protocols in themselves do not provide any topology or
locality awareness. At least some of the policing middleboxes
have worked with network operators to address the need and bring
topology-awareness into varous p2p clouds by eating a BGP feed
to redirect traffic on-net (or to non-transit, or same region,
or latency class or ...) when possible. Of course the on-net
has less long-haul costs, but the last-mile node congestion is
killer; at least lower-latency on-net to on-net trafsfers should
complete quickly if the network isn't completely hosed. One
then can create a token scheme for all the remaining traffic
and prioritize, say, the customers actually downloading over
those seeding from scratch.
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE