Super-Seeders

[discodoc]

Improve downloads by prioritizing upload to super-seeders.

Often, there are only few (or just one) seeders with a very limited band-width. This is especially true for files that are not the latest movie hit or latest pop-single.

In these situations, if a high number of peers connect to those limited seeders, the overall download velocity is quite low and gets lower with more leechers. [basically, all leechers stay at the same downloaded percentage of the file and all try to download the remaining bits from the few seeders.]

I therefore propose a more advanced mechanism:

1.) uTorrent should determine which leechers have a high bandwidth and behave like superseeders (should be possible for other uTorrent clients)

2.) it should preferentially select 2-3 such super-seeders and upload preferentially the file to these

3.) the remaining leechers will download the torrent from these super-seeders.

[jewelisheaven]

Any reprioritization of selective peer preference other than mechanics already implemented has been rejected.

[discodoc]

Well, did you do any simulation testing of existing mechanism against other mechanisms?

I am fairly convinced that no simulations were done.

On what grounds do you then reject a mechanism?

I do know that the theoretical model most p2p programs are based on utterly fail under realistic conditions. This might be not a problem for the nn++ seeders & nn++ leechers scenario, but it is a problem on limited seed-bandwidth.

It seems there were some thoughts on superseeders (see http://bittorrent.org/beps/bep_0016.html) but the document is empty.

I do strongly recommend doing some real life simulations under low-bandwidth seed conditions. It might change your world-view. It could be that some open-source/academia projects will implement something like this, and swoops, the uTorrent lead goes away.

[jewelisheaven]

Super seeding already exists, therefore trying to refer to a new mechanism by the same name may confuse others.

Peers transfer based upon the throughput metric. Skewing piece distribution towards peers which may not stick around only hurts the swarm.

[discodoc]

> Skewing piece distribution towards peers which may not stick around

> only hurts the swarm.

"not stick around": This is not particularly realistic as most high-bandwidth / power-seeders (lets call them differently to avoid confusion) would stick most of the time on the net. Well, uTorrent, being closed source, can implement methods to determine if the other uTorrent client behaves like a power-seeder ("superseeder").

And if a leecher will seed with an average of less than 200 bps and 90% of the time is disconnected (i.e. it connect a couple of seconds, than is away 20s then connects again for 3-5 seconds, then is again away for 30 s), it will be worse than a not-sticking around leecher scenario, because he actually slows down the entire swarm.

And testing such scenarios in simulations can be quite rewarding: the most appealing point is that the metric for the whole swarm improves (contrary to beliefs on this list, the mean or any other statistics like the median download time will improve - and this is what should be measured). You need a substantial drop down to negatively affect the outcome. (And the drop down can be minimized if the uTorrent client implements some seeding-activity reporting for the leecher. I will happily accept such a priorityzation.]

[Switeck]

Just because you've seen the symptoms doesn't mean you understand the problem.

If there's 1 seed and there's 10+ peers all within 0.1% of each other, then chances are it's the SEED that's being slow and inefficient...not the peers. Were the peers particularly inefficient, then you'd see big variations in completion %'s for them...as some would lag behind due to others being slow+unwilling to share the parts only they (and the seed) have.

If a lone seed on a torrent chooses to upload to 4 peers each PER torrent and run 5 torrents at once and only 20 KB/sec total upload speed...then there's really no post-processing that can be done by the peer swarm on the current torrent to make the torrent download faster than 4 KB/sec at best.

Even were µTorrent both 100% efficient and intelligent in its peer choices to upload to...and at what speed...you're still dealing with a random environment which may contain BitTorrent clients (or wannabes) that are often...even USUALLY...set with "default" settings, firewalled, with crappy ISPs, on lines with low upload speeds...or set to upload very slowly and running multiple torrents. So even if you upload to very fast uploading peers...their efforts still get sabotaged by all the bad peers and hit-and-runners (those that stop the torrent very shortly after they finish downloading, often with a share ratio of <25%).

[Ultima]

@discodoc: So by what mechanism would you effectively/accurately determine another peer's connection's max upload speed and/or the upload rate limit the peer has set in the client?

BitTorrent works because it propogates the pieces as widely as it can. Concentrating the bandwidth on a handful of peers goes against the reason BitTorrent works.

[hermanm]

> mechanism would you effectively/accurately determine another peer's connection's

If you have a seedbox, you have control over that peer's settings. I've heard of seeders banning all IPs except seedbox IPs so they can optimize upload rates.

Could you also set up a private tracker on the seedbox where your local client only has access to it. The seedbox announces to the private tracker and the other tracker. My upload only goes to the seedbox then the seedbox distributes to rest of the swarm?

[Ultima]

If you have a seedbox, you have control over that peer's settings.

Doesn't really answer the question.

Yes, it's simple enough to make µTorrent connect only to the seedbox. All you need to do is block all other IPs using ipfilter.dat.

[Switeck]

It would be better to get full pieces out to "random" peers than to 1 peer, just due to redundancy.

The problem is, the time it takes a slow seed to get 1 complete piece out may be over half an hour. (4 MB pieces, uploading to 4 or more peers at once, running multiple torrents, etc...)