Re: [Tsvwg] A coment on "draft-briscoe-tsvwg-relax-fairness-00" re file-sharing

[Bob Briscoe <[e-mail]>]

Robb,

I've split out this more detailed response to your mail - see my 
previous posting for these two responses:
a) Could my scenario become common, even if it's not currently prevalent?
b) The discussion is over what the correct fairness /goal/ should be

c) Who is actually correct for today's Internet?
---------------------------
The 3-4 active connections statement is just as much a fallacy as the 
hundreds of active connections statement. Which you get depends on 
the evolution of the situation over the lifetime of a swarm:
* If the swarm is immature (ie few peers have finished) your peer 
will limit open connections. How many active (unchoked) connections 
you get initially depends on configured upload slots, which is indeed 
about 3-4 per swarm (gets linearly larger for faster access lines - 
see graph in presentation below).
* But if peers stays on line after they have finished (seeders), 
other peers still downloading will activate (unthrottle) connections 
to nearly as many seeders as they can find, irrespective of the 
upload slots limit.

This is because upload capacity is the bottleneck (as you say). But 
once you're no longer downloading, BitTorrent no longer needs to 
preserve your upload capacity for the ack stream that was keeping 
your download going.

In some communities you get a lot of seeders staying online. In 
others, they're all mingey gits who disconnect once they've got what 
they want.

Also, if you're going for niche ('long-tail') content, of course you 
won't get many active connections, as it's hard to find peers.

My presentation of that draft to the Transport Area in Vancouver
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0712relax-fairness>
shows a screen shot of a colleague's Azureus client (taken randomly 
at the time I asked him for it). He had 3 swarms running (fairly 
typical) and 105-114 active TCP data transfer connections, with only 
about 10-15 choked. One of the swarms is shown. You can see ~40 
connections are active in this one swarm. This merely implies there 
were a lot of nice friendly seeders in his swarm.


Bob

At 05:30 12/04/2008, Robb Topolski wrote:
>Comment on
>
>Problem Statement: We Don't Have To Do Fairness Ourselves
>draft-briscoe-tsvwg-relax-fairness-00
>
>
>Dear Working Group members,
>
>Thank you for your time working on this committee and issues such as these.
>
>The above quoted paragraph requires a number of corrections.  This paragraph
>is a basis for the problem statement that follows it -- so getting the basis
>down right is key to analysing the issue and sizing up the problem.  The
>corrections that I hope to effectively communicate seem to me to reduce the
>stated size of the problem.
>
>--Quote--
>Even though file-sharing generally uses TCP, it uses the
>well-known trick of opening multiple connections--currently around
>100 actively transferring over different paths is not uncommon. A
>competing Web application might open a couple of flows at a time, but
>perhaps only actively transfer data 1-10% of the time (its activity
>factor). Combining 50x less flows and 10-100x lower activity factor
>means the traffic intensity from the Web app can be 500-5,000x less.
>However, despite being so much lighter on the network, it gets 50x
>less bit rate through the bottleneck.
>--EndQuote--
>
>I am relatively certain that the draft is talking about BitTorrent above,
>and it unforunately misinterprets what it does.  BitTorrent is the #1 P2P
>File Sharing protocol in use today.  Furthermore, neither #2 P2P file
>sharing protocol ED2K (aka eDonkey, eDonkey2000, eMule, or MFTP) nor #3
>Gnutella (aka G1, G2, or Gnutella2) work like BitTorrent, nor as Briscoe's
>draft described above.
>
>In the case of BitTorrent, between 35-70 TCP connections are generated.
>However, only three or four of these connections are actively transferring
>data.  Therefore, any benefit to the "trick" is erased.  The reason the
>remainder sit idle is described in the specification
>(http://wiki.theory.org/BitTorrentSpecification#Choking_and_Optimistic_Uncho
>king), chief of which is the desire that BitTorrent NOT interfere with TCP
>congestion control.
>
>It is important to remember that P2P users are largely residential users,
>most using connections that are configured with asymmetric connections where
>the maximum download bandwidth allowance is several times that of their
>upload allowance.  In all of the discussions about "fairness" that I've been
>involved in, it has to do with sharing the tiny upload pipe.  Filling the
>generously-configured download pipe is seldom a user fairness concern (it is
>also very difficult to control at the receiving end).  A trend is barely
>beginning toward more symmetrical residential accounts, but it is probably
>too small to accurately determine changes in usage patterns created by it.
>
>That BitTorrent uses "hundreds of connections" that are simultaneously
>active is a common misperception.  While the draft likely did not mean to
>inject emotionalism, the label of "trick" is both inaccurate and
>inflammatory.  The reason that BitTorrent makes these idle connections is to
>allow for one connection to "hunt" for the best reciprocating peer, which
>allows two efficiently located peers to detect and reciprocate with each
>other.  If not interfered with by network operators, this pretty much
>ensures that the lowest-latency peers will eventually find one another and
>engage in a long-term exchange of data.  This is not only fast for the user,
>choosing the most efficient (lowest latency) pairings is friendliest to the
>local ISP network and the Internet as a whole.
>
>All three of the top P2P protocols do open multiple upload connections.
>ED2K seems happiest with 3-4 KB/s upload flows, Gnutella with 10 KB/s upload
>flows, and BitTorrent with anywhere from 3 KB/s to 7 KB/s flows.  Therefore,
>the number of upload flows that a single peer might generate (think
>different archives being sent by the same client simultaneously) is a
>function of dividing the configured upload bandwidth by the amounts
>decribed.
>
>An example:
>
>BitTorrent:  Upload limit set to 20 KB/s, 3-6 upload TCP connections
>(remainder are idle or downloading only)
>ED2K:  Upload limit set to 20 KB/s, 5-6 uploading TCP connections (remainder
>of connections are downloading only or performing light-bandwidth
>housekeeping, such as queue placement requests or updates)
>Gnutella:  Upload limit set to 20 KB/s, 1-2 uploading TCP connections
>(remainder, same as for ED2K).
>
>All three of the above have a UDP component, which is used for searching or
>other light network housekeeping.  There is an emerging use of UDP for "NAT
>hole punching" but these "connections" are still quite rare.
>
>I am happy to answer any questions or further clarify anything that I can.
>
>Sincerely,
>
>Robert M. "Robb" Topolski
>[e-mail]

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]