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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Robb,

Appreciating the following, this isn't intended as an application
protocol, so we can't assume it would apply only to P2P. I.e., we need a
solution that can be used for any application, and there are several
applications that DO use multiple connections to increase bandwidth in
the typical case.

Joe

Robb Topolski wrote:
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ledbat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkl6AUACgkQE5f5cImnZrsx2QCffCgD6jNC1hweFop6H/Kxt8dp
iNUAoJV82/0MoswiovhlI6pLP+KgLWbD
=xDqF
-----END PGP SIGNATURE-----
_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat