BT protocol peer ratios?

[myndzi]

I don't know anything in-depth about the BT protocol, but this has been obvious to me for some time. If there was a way to obtain the ratios (for this torrent) of other peers from the tracker, you could prioritize your uploads to people with the highest ratios. This would be good why? Well, if they are a leecher, their ratio will drop quickly and they won't get much data (assuming all clients behave this way). If they are not a leecher, it means they have some good upload speed, and you get more return for your bits -- sending them to someone with a faster upload speed will spread them around the torrent faster than sending them to someone with a slow upload speed.

The problem with this idea, if you could call it a problem, is that people with low uploads and high downloads (most home broadband), are the ones who take the hit in the download speed since they can't "keep up". This only occurs if the total available upload bandwidth on the torrent is less than the available download bandwidth -- for example, with a single Cable seed when a torrent is first starting off or something like that. However, even in that case, sending the most data to the people with the highest ratio pays off -- the ratio of available UL to available DL increases as you send to the people with the fast uploads.

Added bonus side effect is that people who cap their uploads really low get less return than anybody else.

So anyway, does this make sense to anyone else? Is it possible to implement right now? (I don't think it is...) And if not, what would it take to get support in trackers for this method of choosing peers to send to?

[ColdArmor]

I haven't seen this in a client so I am assuming no it wouldn't work.

[DreadWingKnight]

If there was a way to obtain the ratios (for this torrent) of other peers from the tracker, you could prioritize your uploads to people with the highest ratios.

There isn't a way to obtain the ratios from the tracker, and even if there was, those ratios CANNOT be trusted.

All things considered, the way BT regulates speed within a swarm right now works. Clients that don't play nice don't get treated nice.

[BLu]

I just ban people that don't share, I just watch their UL speed, and the hundreds of requests I sent them that go unfulfiled and ban them.

[chaosblade]

So people that have poor connections get banned for no reason ? You're not playing nice either.

[myndzi]

I haven't seen this in a client so I am assuming no it wouldn't work.

That's just ridiculous. Innovation doesn't happen by "assuming it wouldn't work" because you haven't seen it before. Lucky for us, Bram Cohen doesn't think that way

All things considered, the way BT regulates speed within a swarm right now works.

Works, but could work better. I'm not saying ratios would be used to determine the sole recipients of data, but it would be used to influence it in the same way that the current algorithm is influenced by who *you* have received from. It'd just be more general than that. And it would be a way to optimize the available resources in a torrent.

As for ratios not being reliable, each person reports who they got a chunk from when they complete it. This could possibly be affected by a large number of false clients, but that would give its own tells. One possible way to help detect foul play would be to have the tracker only relay information about clients you are connected to. Then, you only 'trust' clients who have been sending you valid information. After all, there's no point spoofing clones in to send legitimate data.

It's not as infeasible as you make it out to be, at any rate.

[ColdArmor]

I haven't seen this in a client so I am assuming no it wouldn't work.

That's just ridiculous. Innovation doesn't happen by "assuming it wouldn't work" because you haven't seen it before. Lucky for us' date=' Bram Cohen doesn't think that way [/quote']

Sure, but this is so general that a client would have tried to do it before, I guess I could have worded my post differently, but meh..

[myndzi]

Sure, but this is so general that a client would have tried to do it before, I guess I could have worded my post differently, but meh..

I suspect it's because the protocol doesn't allow for it. That doesn't mean that it couldn't, however. Look at DHT, that's not part of the original BitTorrent "plan"... anyway, I was just looking for someone with protocol knowledge to tell me how easily it could be implemented.

[Firon]

It'd require a change in the tracker protocol to be possible, and you'd have to prevent it from screwing over peers who've downloaded only a small amount.

[chaosblade]

I dont think its so accurate to count by ratio. There are alot of alternative sceneraios where peers would get 'screwed over' as Firon said.

[DreadWingKnight]

As for ratios not being reliable, each person reports who they got a chunk from when they complete it. This could possibly be affected by a large number of false clients, but that would give its own tells. One possible way to help detect foul play would be to have the tracker only relay information about clients you are connected to. Then, you only 'trust' clients who have been sending you valid information. After all, there's no point spoofing clones in to send legitimate data.

It's not as infeasible as you make it out to be, at any rate.

Looking over the amount of extra data that would need to be exchanged between the peers and the tracker, the overhead added would be enormous, and all the previous developments tracker-side have been to SAVE bandwidth to be able to handle MORE peers. This proposal will make it so that trackers handle LESS.

Even if you only request ratios on those you're connected to, you have to realise how reliable the data the tracker has on those peers is. (It's not, because of how easy it is to spoof data for those ratios)

BitTorrent as a protocol was developed to give content providers a way to reduce bandwidth costs by offloading some of the upload demand to people who download from them. It wasn't really intended to enforce that people upload 100% or more of what they download.

[Animorc]

The ratio dependant speed will be really boresome if you download a torrent with 4MB pieces, since your ratio is 0 until you have finished downloading one piece and can begin uploading.

[RS]

So people that have poor connections get banned for no reason ? You're not playing nice either.

But if you have a peer where you get -5kb, but your upload speed to him is 40kb, that's not nice either... a good part of the peers have their upload speed limited.

[myndzi]

Looking over the amount of extra data that would need to be exchanged between the peers and the tracker, the overhead added would be enormous, and all the previous developments tracker-side have been to SAVE bandwidth to be able to handle MORE peers. This proposal will make it so that trackers handle LESS.

It already relays to clients the pieces that other clients have/don't have. This is less info than that, in fact it could probably be tacked onto the same packet for an extra few bytes (yes I realize a few bytes * a lot of users = a lot of bytes).

Even if you only request ratios on those you're connected to, you have to realise how reliable the data the tracker has on those peers is. (It's not, because of how easy it is to spoof data for those ratios)

That's why you don't rely on the client, you base it on the clients that have received from that client. Nobody is going to spoof 'received' packets since that would just lower their ratio.

BitTorrent as a protocol was developed to give content providers a way to reduce bandwidth costs by offloading some of the upload demand to people who download from them. It wasn't really intended to enforce that people upload 100% or more of what they download.

You misunderstand my purpose. I am heartily against enforced ratio trackers. What I am saying is that this method would make the entire torrent go faster, since the ones getting the most data are the ones sharing the most (fastest).

[myndzi]

It'd require a change in the tracker protocol to be possible, and you'd have to prevent it from screwing over peers who've downloaded only a small amount.

The ratio dependant speed will be really boresome if you download a torrent with 4MB pieces, since your ratio is 0 until you have finished downloading one piece and can begin uploading.

That's easy to fix. Either start ratios at 1, or don't count them at all until the peer has a certain amount of data (either a set size or percentage of the torrent size). You could even segue one into the other mathematically.

But if you have a peer where you get -5kb, but your upload speed to him is 40kb, that's not nice either... a good part of the peers have their upload speed limited.

I'm not interested in being nice, I'm interested in optimizing the torrent. He'll get his... if his upload speed is limited to 5kb then maybe his download speed will be ~5kb. That's the worst case scenario, where the available UL bandwidth is less than the available DL bandwidth by too much. But think about this: we are increasing the ratio of available UL to DL bandwidth. We are making the entire torrent go faster, and his 5kb download speed will begin to increase as this happens. Prioritizing doesn't mean exclusively sending to people with good ratios, it means weighting your choice towards them.

[RS]

I'm not interested in being nice, I'm interested in optimizing the torrent. He'll get his... if his upload speed is limited to 5kb then maybe his download speed will be ~5kb. That's the worst case scenario, where the available UL bandwidth is less than the available DL bandwidth by too much. But think about this: we are increasing the ratio of available UL to DL bandwidth. We are making the entire torrent go faster, and his 5kb download speed will begin to increase as this happens. Prioritizing doesn't mean exclusively sending to people with good ratios, it means weighting your choice towards them.

Still, when I see a guy that has a bigger % of the torrent, has leeched from me 800mb but only sent me around 50mb and will finish the download before me (I've seen plenty of times those peers starting after me but finishing before), that pisses me off.

I can perfectly understand that there are people out there with little bandwidth, who can't really share the torrent as it should be. I talk about the ones that have the bandwidth but choose only to get and cap thier upload as to not "cripple their connection".

Sure, if you set the upload to unlimited, web browsing might get a little laggy but why set it to 90% or so?

[ColdArmor]

I leave mine at unlimited and browsing isn't too bad most of the time.

[RS]

I leave mine at unlimited and browsing isn't too bad most of the time.

I set mine at 90% for the day and unlimited at night

[myndzi]

Still, when I see a guy that has a bigger % of the torrent, has leeched from me 800mb but only sent me around 50mb and will finish the download before me (I've seen plenty of times those peers starting after me but finishing before), that pisses me off.

I can perfectly understand that there are people out there with little bandwidth, who can't really share the torrent as it should be. I talk about the ones that have the bandwidth but choose only to get and cap thier upload as to not "cripple their connection".

Sure, if you set the upload to unlimited, web browsing might get a little laggy but why set it to 90% or so?

I don't understand what you are getting at. If there's a peer crippling their upload, they will have a low ratio and be near the end of the priority queue -- won't receive as much data until their sharing brings them back up closer to 1:1.

On an unrelated note, if a peer has leeched 800 megs from *you*, that may very well mean that most of what he has, you already have -- thus the low return. If you started first it is very likely he simply has nothing to send you for quite some time.

[JigPu]

Sure, if you set the upload to unlimited, web browsing might get a little laggy but why set it to 90% or so?

I'm not your average user, but one reason that I limit bittorrent is because it really hurts my Apache upload. 50KB of upload bandwidth only goes so far, and I'd love to find a way to do QoS so that uTorrent can use all my upload when Apache isn't (and also use almost none when Apache is).

JigPu

[Firon]

If you have both on the same machine you can use cFosSpeed to perform QoS on a machine level, but if you don't, you'll need a router with QoS.

[RS]

On an unrelated note, if a peer has leeched 800 megs from *you*, that may very well mean that most of what he has, you already have -- thus the low return. If you started first it is very likely he simply has nothing to send you for quite some time.

If he finishes before me, then he has data I don't. Remember I can see his % progress.

That aside, There should some king of control for the hush fails (I don't know if there is one on utorrent). Yesterday I was dl a 2gb torrent and I had around 400mb of hush fails. Then utorrent made me upload to cover my share the 2gb plus the 400mb (made the amount of the total size of the torrent to 2,4gb)

[myndzi]

If he finishes before me, then he has data I don't. Remember I can see his % progress.

Yeah, but he can only send so fast. I didn't know the torrent size in question but it is certainly conceivable that he finished and hopped off before getting a chance to 'repay' you. Anyway, looking at BitTorrent that way only gives people headaches. You get what you get and you send what you send. Healthy torrents have enough bandwidth to go around, and everyone gets good. Unhealthy torrents don't. BitTorrent seems to have gotten sorta hijacked by the 'community' and used at cross purposes to the original intent. It is best used with a seed (or set of seeds) with a good chunk of bandwidth to begin with. Not some home Cable connection.

That aside, There should some king of control for the hush fails (I don't know if there is one on utorrent). Yesterday I was dl a 2gb torrent and I had around 400mb of hush fails. Then utorrent made me upload to cover my share the 2gb plus the 400mb (made the amount of the total size of the torrent to 2,4gb)

Er... you mean hash fails right? Erroneous data probably shouldn't be counted in the ratio calculations, I agree. 400 mb of fails is quite a lot though... yet you completed the torrent fine? I knew someone with a bad sector in a hard drive once and he was complaining of insane amounts of hash fails on a given piece...

Anyway, I guess I've got all the feedback this thread is good for so I'll leave you all to your various devices.

[BLu]

Well I personaly am angered when the people that can only upload at 5kbs get the file first, not only does that slow everyone down because he is taking up more of the avalible bandwidth, but when he is done he will upload a lot slower than other people such as me would.

[ColdArmor]

If he finishes before me' date=' then he has data I don't. Remember I can see his % progress.[/quote']

Yeah, but he can only send so fast. I didn't know the torrent size in question but it is certainly conceivable that he finished and hopped off before getting a chance to 'repay' you. Anyway, looking at BitTorrent that way only gives people headaches. You get what you get and you send what you send. Healthy torrents have enough bandwidth to go around, and everyone gets good. Unhealthy torrents don't. BitTorrent seems to have gotten sorta hijacked by the 'community' and used at cross purposes to the original intent. It is best used with a seed (or set of seeds) with a good chunk of bandwidth to begin with. Not some home Cable connection.

That aside, There should some king of control for the hush fails (I don't know if there is one on utorrent). Yesterday I was dl a 2gb torrent and I had around 400mb of hush fails. Then utorrent made me upload to cover my share the 2gb plus the 400mb (made the amount of the total size of the torrent to 2,4gb)

Er... you mean hash fails right? Erroneous data probably shouldn't be counted in the ratio calculations, I agree. 400 mb of fails is quite a lot though... yet you completed the torrent fine? I knew someone with a bad sector in a hard drive once and he was complaining of insane amounts of hash fails on a given piece...

Anyway, I guess I've got all the feedback this thread is good for so I'll leave you all to your various devices.

wow, seriously, how do you get 400mb in hashfails.. lol