Re: [ledbat] list of reasons for needing multiple TCP connections

I want to eliminate the "bandwidth hogging" motive in using multiple P2P
connections to get more traffic across a congested network.  Neither the
facts nor the personalities of the developers involved support that charge.
It's a huge and false distraction from what may be good work at hand.

P2P apps, users, protocols, developers do not use multiple connections to
get an unfair "leg up" across any point of congestion...

THAT TRICK WON'T WORK ON SPEED-CAPPED CONNECTIONS: While it's true that
larger number of standard TCP connections can allow a greater share of
bandwidth across any particular point in the network, getting that bandwidth
depends on a lack of any other limiting factor.  In our residential
networks, however, the subscriber's broadband modem imposes relatively low
ceilings.  A single connection can get maximum speed either in or out.
Therefore, any "bandwidth-hogging" benefit of running multiple connections
on these broadband access networks is very temporary at worst (about the
time it takes for the multiple streams to all get knocked down and find new
equilibrium) and may actually work out to be nil (giving that all the
streams will respond eventually in relatively proportionate ways).

P2P DOESN'T USE THAT TRICK: The slot-and-choke (used by BitTorrent) or
queue-list techniques (used by Gnutella or ED2K) and similar used by others
tends to limit the number of connections actually in use vs. disconnected or
occasionally sending tiny bits of mesh data.  Just like any other sender of
information, P2P uploads are overall faster and more efficient when they
respond to congestion signals than they are when they ignore them.

P2P AVOIDS CONGESTED ROUTES: Sources for data that are on congested routes
are used less often and for shorter times than sources on routes that are
free of congestion. BitTorrent does this by reserving all but one of its
slots for the fastest reciprocating peers and by reserving one slot to hunt
for even faster peers (the presumption being that slow peers indicate
congested routes).  In Gnutella and ED2K, peers are usually both time and
data limited -- so if the clock expires before a chunk is fully transferred,
the transfer is ended.  This has the net effect of getting the most data
from peers without such a constraint.

USING MULTIPLE CONNECTIONS HAS NOTHING TO DO WITH BANDWIDTH CONSUMED: In one
of the presentations, the speaker seemed to tie the use of multiple
connections to bandwidth consumption.  The consumption of bandwidth,
however, has everything to do with the size of the object being transferred
and nothing to do with the number of connections.  Take the task of
downloading and sharing the Knoppix DVD.  If the multiple connections were
replaced by single connections, the bandwidth consumed would be essentially
the same (about 10 GB). The additional overhead is hardly worth mentioning.

There is a related -- almost rhyming -- motive, but it's not an evil motive
as far as the network is concerned.  Some users observe that being connected
to more peers results in faster downloads.  This is -not- because anyone is
ignoring congestion signals, it's simply because more connections gives a
downloader access to a larger number of altruistic "seeders" (sources who
will upload without an immediate expectation of reciprocation).  These
seeders are still operating under the same network rules as other nodes,
uploading only on a very limited number of their connections and responding
to signs of congestion control.  (And most users don't realize that seeders
have little motivation to transfer exclusively to them, so while that trick
works, it doesn't work as well as many expect. Many users are disappointed
in the download rates experienced within heavily seeded swarms.)

There is room for improvement -- like any other network use, P2P
file-sharers have shown that they are very interested in efficiency and are
adaptive to technology or techniques that gets them there.  P2P file sharing
is not perfect, either socially or technologically.  There are network
cheaters and generally dumb ideas out there.  While I'm speaking generally
of typical P2P users, developers, and protocols -- there will always be the
few exceptions.  While nobody has targeted these exceptions as the biggest
part of "the problem," I didn't want the above info to be interpreted as
ignoring the fact that they exist here and there.