[BitTorrent] An alternative "super-seed" mode

Jesus Cea jcea at argo.es
Sun Jan 30 20:39:55 EST 2005

Mike Ravkine wrote:
>>2. What if a peer transfer a piece to another peer, but that peer goes
>>offline?. The seeder never saw the transfer and penalize the first peer
>>not sending it more "have" messages ever. So that peer will be 
>>completely ignored.
> This isn't a problem, as the piece will still eventually show up on 
> another peer.

No if the peer has died. While, the original peer keeps being "ignored".

>>With this environment i'm confused. The original Super-seed algorithm 
>>works fine if the swarm is big, but my original proposal seems to do a 
>>better work if the swarm is very small (let say, 5 peers).
> What you're trying to do is maximize download speed for every member of 
> the swarm. This is NOT THE SAME GOAL as superseed.

I understand. In fact doing some calculations, the stationary state for 
my algorithm is that each peer, if launched simultaneously, reach full 
download state at the very same time, if they download speed is high 
enough to match the seeder. That is the case for my environment.

More later.

I must insists in that my network is a bit particular. It is a -very- 
small swarm. We are trying to get maximum efficiencies in a private and 
very assimetric network. Something like this:

- Seeder: 512Kbps.

- Peers: 512/128Kbps (about a dozen, 1-4 active for each torrent)

- Superpeer: Unlimited BW. This node is interested in very few torrents.

The swarms are so small that the choke algorithm is not activated, I 

> What are you efficiency measurements with and without superseed, and 
> with your modified superseed?  I'd like to see some numbers..

I'm having now about 150-200% BW usage. I've not using superseed 
(standard BT client doesn't support it) and my proposal is only a 
proposal; no code yet. In fact this mesages were trying clarify the 
situation before touching any code :).

But we can do some math:

For a torrent with two 512/128Kbps peers (and the seeder):

1. For the standard algorithm, seeder sends 256Kbps to each peer. Each 
peer sends 128Kbps to the other. So, each peer gets 384kbps. The BW 
usage for the seeder will be 133'3%, if the seeder feeds the swarm all 
the time. If it stops feeding it when te entire file is out (100% BW 
usage), the peers will feeds each other at 128kbps. That instant will be 
when each peer has 66'6% of the file. So median speed for peers will be 

2. For standard "Super-Seed", supposing pipelining to keep the pipe 
full, you only send a new piece to peer A when peer B confirms transfer 
A->B for the previous one. So, the seeder only sends as fast as upload 
speed of peers. In this case, 128Kbps for each one. The peer crossfeed, 
so each get 256Kbps, in total. 100% BW usage.

3. My approach sends the new piece to peer that receive less lately, 
from other peers. In this case, both are equal so, they get the same 
share, or 256Kbps from seeder and 128 from the other peer. 384Kbps in 
total. We are in case 1.

In this calculation, with two peers, superseed is the worst algorithm, 
in download speed terms.

For a swarm with a 512/128Kbps peer and the unlimited peer.

1. Standard: seeder sends 256 to each. The peer A sends 128 to peer B, 
but peer B send 256 to fully use download speed of A. So A gets 512Kps, 
and peer B gets 384. The slower peer gets the full file earlier!. If the 
seeder stops feeding then (100% BW usage), the peer B will get only 
128Kbps, when his file is 75%. So the median speed for it is 320Kbps. If 
the seeder keeps feeding, peer B will get 640Kbps for the last 25% of 
the file. The median speed for B will be 448Kbps. BW: 125%.

2. Super-Seed: A gets 128Kbps from seed, B gets 384Kbps from seed, since 
it sends 384 to A before saturating its line. So in total both gets 
512Kbps. BW: 100%.

3. My Approach: In the stationary state (the process is iterative), peer 
A gets 128Kbps from the seeder and B gets 384 from seeder. Both download 
512Kbps in total. BW: 100%

The situation can be complicated, for example, if the peers don't start 
the download at the same time. But doing some calculations, the 
conclusion seems to be:

1. Super-seed tries to reach a BW usage of 100%. Each peer gets a 
different piece to trade. If the trading is going slow, the seeder slows 
tranfer in order to avoit piece duplication. So the swarm must be big in 
order to use the full seeder capacity.

2. My approach, instead, tries to optimize download speed. If the 
(summed) upload capacity of peers is below seeder speed, the seeder will 
duplicate blocks, unless it stops feeding. Each peer will get pieces 
from seeder proportionally to its upload capacity.

My approach is fairly simple, but has a serious flaw: if a peer is being 
choked because it's sharing poorly, my algorithm will give it 
priority!!!. That could disturb the tit-for-tat BitTorrent algorithm. In 
my environment, nevertheless, I'm not sure if the choke would get in 
action, since the swarm size is very small. The algoritm, in fact, is 
acting appropiatelly for its purpuse: optimice the download speed of the 
swarm, in this case feeding the slower (and more "leech") node };-).

Food for the mind.

Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                       _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list