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

["Robb Topolski" <[e-mail]>]

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]