Re: Potential DoS on Bittorrent

Probably not on-topic for sci.crypt, but then again, half the stuff on here
isn't on topic either.

"anthonyberet" <nospam@me.invalid> wrote in message
news:3nddn1FvoqnU3@individual.net...
>>>>Why are sub pieces downloaded from multiple clients ? Why not simply one
>>>>client ?

Sub pieces are there under the assumption that disk reads are expensive and
more small disk reads will actually be more efficient in the highly
distributed setting than fewer large disk reads. Whether or not this is true
at typical bittirrent sizes is debatable is open to debate, but
asymptotically it will be true. The other occassion where the sub pieces
come into play is in the end game, where when only a certain small number of
pieces is left the ability to request from multiple sources diminishes very
quickly. As the sub pieces are available the distributed nature can be
accelerated to much closer to the file complete state. This in effect
reduces the end game overhead which can become very high. For example in
large swarms it is not necessarily bad form to request the last piece from
16 different peers, in a monolilthic sub piece form this is 16*piece size,
since pieces are generally on the order of 256KBytes this represents a
download of 4MB for the last 256KB, not exactly efficient, and with growing
swarms we are beginning to see where it could be considered acceptable from
a download perspective to download from in the neighborhood of 100 different
peers. By creating the sub piece it becomes possible to shrink the example
from 4MB to 1/4MB. The downside, as noted by others I'm certain, is that the
protocol does have some extra overhead. Since I actually have a client
running right now I can tell you that the current overhead it is receiving
is 0.9%, assuming a CD sized average download (640MB for simplicity), and a
256KB piece size eliminating the sub pieces would save 5.4MB worth of
download, while in a large swarm it would save >10MB in the end game, making
the overhead a multi-megabyte benefit on each download, multiple the benefit
by the large swarm size and the swarm has saved GBs worth of transfer.

>>>>That would solve it.

In fact during the meaty times of the download that is very typical, because
BitTorrent uses HTTP to perform the actual transfers you will see a number
of optimizations in the requests.

>> 1. more protocol overhead for sub piece information/negotiation ?

Sub piece information is not distributed. This is due to the fact that sub
pieces are not hashed and verified, and there is a very specific provision
against uploading a piece that has not been verified.

>> 2. tcp needs some time to get at top speed... having to restart all the
>> time
>> doesnt seem that wise ;)

It's actually not restarted, the connection remains open and a series of
HTTP requests are sent over it.

>> 1. Maybe faster switching to different clients etc. Not necessarly faster
>> sharing since a complete piece has to be received first to check if the
>> piece was received correctly... unless one doesnt care about that and
>> simply
>> uploads possible corrupted sub pieces etc ;)

> Don't forget the size of the pieces in a torrent can be defined when
> generating the .torrent file.

That they can, but the shift from a 256KB piece to the requisite 16KB piece
would create a 16x increase in the size of the torrent file itself which
begins to move the burden out of the swarm and back onto the assumedly HTTP
server that is used for the torrent file. In fact there is a movement within
the BitTorrent community to move to an embedded Merkle tree reducing the
torrent file down to the size of a URL, and there is a notable amount of
evidence that this can substantially improve performance.

Now, why was sci.crypt added to this? Was it just so you could get me to
reply? If you had asked the same question on the BitTorrent discussion list
you would've gotten answers that are equally qualified.
                    Joe
Received on Thu Sep 29 21:51:20 2005