RE: Can P2P applications learn to play fair on networks?

[<michael.dillon () bt com>]

> And of course, if you still believe just adding bandwidth 
> will solve the problems

Joe St. Sauver probably said it best when he pointed out in slide 5 here
<http://www.uoregon.edu/~joe/i2-cap-plan/internet2-capacity-planning.ppt
>

   the "N-body" problem can be a complex problem to try to
   solve except via an iterative and incremental process.

I expect that is why sometimes adding capacity works and sometimes it
doesn't. This is the sort of situation that benefits from having an
architectural vision which all the independent actors (n-bodies) can
work towards. A lot of P2P development work in the past has treated the
Internet as a kind of black box which the P2P software attempts to
reverse engineer or treat simplistically as a set of independent paths
with varying latencies. 

If P2P software relied on an ISP middlebox to mediate the transfers,
then each middlebox could optimize the local situation by using a whole
smorgasbord of tools. They could kill rogue sessions that don't use the
middle box by using RSTs or simply triggering the ISP's OSS to set up
ACLs etc. They could tell the P2P endpoints how many flows are allowed,
maximum flowrate during specific timewindows, etc.

This doesn't mean that all the bytes need to flow through the
middleboxes, merely that P2P clients cooperate with the middleboxes when
opening sockets/sessions.

--Michael Dillon