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