Re: [tlug] Bittorrent Newbie

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Edward" == Edward Middleton <edward@example.com> writes:

    Stephen> No, it's supposed be more bandwidth efficient (ie, it
    Stephen> uses unsaturated bandwidth, which---except for
    Stephen> packet-metered connections---is free), and slower.

    Edward> That is not what bandwidth efficiency means.  For lack of
    Edward> a better definition it is a relationship between the
    Edward> transfer speed to the bandwidth used.

Er, that's optimistic.  There is _no_ technical definition, at least
not that I could recognize in the first ten pages of Google output for
"bandwidth efficiency definition dictionary".  From that sample
"bandwidth efficiency" seems to be a marketing buzzword for "effective
use of available bandwidth".

I choose to view this from a global standpoint, ie, maximum network
flow, not maximum flow for an individual downloader.

    Edward> If you are talking about downloading a file the upstream
    Edward> bandwidth is just wasted bandwidth (protocol overhead),
    Edward> which is why the bittorrent protocol is less bandwidth
    Edward> efficient then FTP.

Your solipsism is showing.  The upload bandwidth is somebody else's
download bandwidth.  It is therefore not overhead or wasted from the
point of view of protocol design.  The protocol overhead is that
incurred in talking to the coordinating server, and any handshaking
that goes on.

    Edward> If you are using ftp to download a file your download
    Edward> bandwidth is limited by the servers bandwidth.

    >> Which may or may not be the bottleneck; typically it is not for
    >> servers that offer FTP.

    Edward> Bittorrent is solving a different problem to the FTP
    Edward> protocol. Bittorrent is designed to combat the slashdot
    Edward> effect that even the most well provisioned FTP server
    Edward> can't, or don't wish to deal with (i.e. will block with
    Edward> user or file size limits).

That's right.  Bittorrent is intended to be effective in mob scenes,
or when a small number of connections can saturate bandwidth for
extended periods (eg, if you mostly distribute >100MB ISO images), not
in day-to-day situations where saturation is infrequent.

Scott strikes me as an intelligent person.  I rather suspect he avoids
mob scenes, and so is not going to benefit from regularly
participating in situations where bittorrent's design wins big.

    >> It is true that bittorrent allows servers with piss-poor
    >> connectivity to serve larger files than they could by FTP, but
    >> by that very token you're unlikely to actually observe them in
    >> reality.

    Edward> And CD and DVD piracy is unlikely to be observed in
    Edward> reality ;)

What's the smiley for?  Irrelevance is hardly amusing.  Put it this way:
How many bandwidth-poor-as-piss public FTP servers can you name?

More important: how many of them does Scott use?

    >> and much of the time they are likely to be slower on the same
    >> hardware.

    Edward> How about you say something concrete.

If you want the math, I'll give you the math.  It'll take a couple
weeks, but I was planning to write the paper anyway.  (Most of it is
already in Bram's papers, but not all of it.)  Please remind me. :-)

    Edward> Who's hardware, are you including the network?

The server is hardware, and of course I'm including the network.
There are few systems with bandwidth enough to saturate their CPUs.

    >> [bittorrent is] limited by the minimum of the sum of the
    >> bandwidths of the active nodes and the minimum of your upload
    >> and download bandwidths.  In other words, torrents are going to
    >> be slower on ADSL.

    Edward> In a perfect world were FTP server resources are unlimited
    Edward> and FTP bandwidth limits don't exist.

Um, no.  I'm assuming that the server resources, including bandwidth,
are limited, but generally larger than possessed by most of the nodes
in any given torrent.  In that situation, you're limited by the
weakest link, which by my assumption is not the server (unless very
heavily loaded), but rather the user's link.

If you can show me these bandwidth-poor FTP servers, I'll retract that
assumption, of course.  But it's also true that the assumptions you
implicitly make are very favorable to bittorrent, failing to take the
endpoint effects into account.  And those effects are very important
for those who don't make a habit of downloading stuff just because all
the other kiddies and anonymous cowards are downloading it.

I'm willing to bet Scott is one such user, and it's his observations
we're trying to understand.

    Edward> In the real world it will depend on how active the torrent
    Edward> is, and how loaded the FTP server is.

In the real world FTP servers are generally bandwidth-limited, not
load-limited.  For this reason they limit the number of connections
and establish preference classes.  If you can connect to the server at
all, generally you will get pretty good transfer rates.

And of course you're completely ignoring the "A" in "ADSL", which
gives the FTP connection a huge advantage over a torrent.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.