Can P2P applications learn to play fair on networks?

Sun Oct 21 07:24:34 UTC 2007

Much of the same content is available through NNTP, HTTP and P2P. 
The content part gets a lot of attention and outrage, but network 
engineers seem to be responding to something else.

If its not the content, why are network engineers at many university 
networks, enterprise networks, public networks concerned about the impact 
particular P2P protocols have on network operations?  If it was just a
single network, maybe they are evil.  But when many different networks
all start responding, then maybe something else is the problem.

The traditional assumption is that all end hosts and applications 
cooperate and fairly share network resources.  NNTP is usually considered 
a very well-behaved network protocol.  Big bandwidth, but sharing network 
resources.  HTTP is a little less behaved, but still roughly seems to 
share network resources equally with other users. P2P applications seem
to be extremely disruptive to other users of shared networks, and causes
problems for other "polite" network applications.

While it may seem trivial from an academic perspective to do some things,
for network engineers the tools are much more limited.

User/programmer/etc education doesn't seem to work well. Unless the 
network enforces a behavor, the rules are often ignored. End users 
generally can't change how their applications work today even if they 
wanted too.

Putting something in-line across a national/international backbone is 
extremely difficult.  Besides network engineers don't like additional
in-line devices, no matter how much the sales people claim its fail-safe.

Sampling is easier than monitoring a full network feed.  Using netflow 
sampling or even a SPAN port sampling is good enough to detect major 
issues.  For the same reason, asymetric sampling is easier than requiring 
symetric (or synchronized) sampling.  But it also means there will be
a limit on the information available to make good and bad decisions.

Out-of-band detection limits what controls network engineers can implement 
on the traffic. USENET has a long history of generating third-party cancel 
messages. IPS systems and even "passive" taps have long used third-party
packets to respond to traffic. DNS servers been used to re-direct 
subscribers to walled gardens. If applications responded to ICMP Source 
Quench or other administrative network messages that may be better; but 
they don't.