how-to block ads
|
robo_mojo
join:2006-01-11
Ada, OK
edit:
March 15th, @04:31PM
| Game Theory?
A species of animals that ruthelessly kills each other for food goes extinct. Only a few individuals of the population can be selfish and take advantage of the others, there has to be a careful balance that has to be checked. If everyone adopts the selfish strategy, you can kiss your species goodbye.
A swarm full of leechers who do not upload also do not download. It is only by the "optimistic" nature of OTHER (non-selfish) clients in the swarm that the selfish clients even get a chance. Take away the optimistic elements of the protocol, and you have no transfers (or at least severely restricted transfers, and unoptimal piece distributions).
I guess it is to be expected. Humans have a long and depressing history of taking advantage of each other. It was just a matter of time before some individuals designed BT clients to mirror this behavior. 
But anyway... Sheesh. If we're all gonna be designing and using selfish clients, we might as well all be using FTP instead! | |
russotto
join:2000-10-05
Collegeville, PA
| The theory behind BitTorrent's tit-for-tat scheme is that these leeching clients will end up with poorer transfers.
The studies done on BitThief showed that this wasn't true when there were plenty of seeders available, but in that case it hardly matters. They also showed that if you connected to a whole lot of clients, you could do will even just getting the optimistic slot... but again, for this to work requires a healthy swarm. So yes, you can be a parasite on a strong swarm and still do OK. So what? Parasites can be tolerated under those conditions; they're only a moral and aesthetic problem, not a practical one.
Greedy Torrent doesn't mess with the mechanics of the swarm at all, as I read it. It merely lies to the tracker. With most trackers, this has no real practical effect. The intended use is to get around upload/download ratio requirements which simply cannot be met. There should be some way of encouraging a leecher to remain as a seeder after he gets everything, but ratio requirements don't do that; they end up penalizing people who download from a well-seeded stream. | |
robo_mojo
join:2006-01-11
Ada, OK
edit:
March 15th, @10:09PM
| I think you misunderstood what I was saying. I'm very much aware that a selfish client can do well for itself in a healthy, *optimistic* swarm. Just like a selfish individual in an animal species can do well provided that most of his kind are not selfish.
Right now, there is an incentive to use selfish clients. The incentive being you can get better benefits against an otherwise optimistic swarm when you are selfish.
The potential problem is that if *everyone* takes the incentive (meaning everyone becomes selfish), then there are no more optimistic peers left to take advantage of, and the incentive disappears. Remember that the optimistic elements of peer transfers is one of the key properties of the BT protocol. BT would not be the same without its optimistic parts.
Ideally, nobody would take the incentive to be selfish, but that is just wishful thinking.
If a swarm is full of such selfish clients (with little or no optimistic elements left), then we will see some great effects on performance all around (like unoptimal piece distribution, poor speeds, etc).
When that happens, there will be little incentive for anyone to go back (there would be no potential benefit for an optimistic peer to participate in a selfish swarm, such a peer would just get taken advantage of and gain nothing).
Then what would be left? BT would effectively be dead. People would be wondering what the heck happened. Why would that matter, though?
That may be exactly what some people want. But users should be aware of the consequences, if they are at all interested in the persistence of BT.
If it ever gets to that point, where everyone is using selfish (non-optimistic) clients, then we might as well be using FTP to share files. There would be no more point in using BT.
said by russotto  :Greedy Torrent doesn't mess with the mechanics of the swarm at all, as I read it. It merely lies to the tracker. With most trackers, this has no real practical effect. The intended use is to get around upload/download ratio requirements which simply cannot be met. There should be some way of encouraging a leecher to remain as a seeder after he gets everything, but ratio requirements don't do that; they end up penalizing people who download from a well-seeded stream. I agree with you there. Ratio limits are ultimately worthless as there is no practical way to verify the statistics that the users provide to the tracker. It is silly to even have such a requirement in the first place. Similarly, it is silly to ban clients based on the name they provide. The BT protocol was not designed to be secure in this way, and it is not so simple to come up with a reliable security model that would work in such an environment, either.
That doesn't stop people from feebly trying, though. | |
robo_mojo
join:2006-01-11
Ada, OK
edit:
March 16th, @03:46PM
| reply to russotto
Also, I'm not just talking about Greedy Torrent, which you say doesn't mess with the swarm, but all of the supposed "selfish" clients that DO mess with the swarm, more specifically. The original topic mentioned several selfish clients explicitely, though the article itself is just about Greedy Torrent. | |
SSidlov
Other Things On My Mind
Premium
join:2000-03-03
Pompton Lakes, NJ
 ·Cingular Wireless
 ·Optimum Online
 ·Optimum Voice
·Cingular Wireless
| reply to russotto
Re: tracker rejection
FWIW: I use BitComet. I find that there are many trackers who while they certainly allow me to download- and I can get 1400kbps on a file's download, when my client is finished, doesn't want me as a seeder, and forces BitC into a loop of trying to be a seeder, but is not allowed to by the tracker.
Perhaps this rejection is based on the bandwidth allocated which is set the way it is so as to not get me capped by OOL (based on a conversation with OOL capping group). I have no problem letting my files seed and server for days until they reach a preset ratio, and have had many large files seed for weeks. But, if I see that I can't connect any longer to the tracker, I just stop the torrent, and I can't feel guilty about it. BitC will stop if the client is unable to connect a certain amount of times, but the number of seeds has to be above a certain amount; the default value is 5.
In one group's tracker, when the above occurred, I went back to the BT tracker they use which requires a login, and redownloaded the torrent. BitC restarted the torrent, found/calc'd that I already had the full file, and the tracker allowed me to be part of the swarm, seeding. So, in at least this case, for whatever reason I timed out, even though my IP address had not changed. I consider this particular case, a problem on their end trying to make the tracker private; being overly cautious.
--
»www.Warpstock.org | |
russotto
join:2000-10-05
Collegeville, PA
| reply to robo_mojo
Re: Game Theory?
said by robo_mojo :Right now, there is an incentive to use selfish clients. The incentive being you can get better benefits against an otherwise optimistic swarm when you are selfish. The potential problem is that if *everyone* takes the incentive (meaning everyone becomes selfish), then there are no more optimistic peers left to take advantage of, and the incentive disappears. Remember that the optimistic elements of peer transfers is one of the key properties of the BT protocol. BT would not be the same without its optimistic parts. Two things
1) The advantage obtained by BitThief wasn't due to its selfishness, but by the fact that it connected to a whole lot of peers (IIRC, 200 instead of 50). There's no reason a non-selfish client couldn't avail itself of the same advantage, leaving reduced upload bandwidth as the only advantage of the selfish client
2) (and this is the key one) As the number of selfish clients goes up and performance starts to drop, it drops _faster_ for the selfish clients. This means the selfish-client phenomenon is self-limiting.
When that happens, there will be little incentive for anyone to go back (there would be no potential benefit for an optimistic peer to participate in a selfish swarm, such a peer would just get taken advantage of and gain nothing).
On the contrary; on a stream with a few non-selfish peers, the non-selfish peers will communicate parts among themselves much more readily than they will with the selfish ones. | |
robo_mojo
join:2006-01-11
Ada, OK
edit:
March 20th, @05:08AM
| said by russotto :1) The advantage obtained by BitThief wasn't due to its selfishness, but by the fact that it connected to a whole lot of peers (IIRC, 200 instead of 50). There's no reason a non-selfish client couldn't avail itself of the same advantage, leaving reduced upload bandwidth as the only advantage of the selfish client Have you read their proposal, lately? Here is a part of it:
We developed a BitTorrent client that free rides on BitTorrent, that is, it downloads from BitTorrent swarms without contributing any resources itself which illustrated that the BitTorrent protocol currently fails to prevent uncooperative behavior as it does not provide any countermeasures against free riding clients.
We argue that the BitTorrent protocol has to be modified in order to effectively prevent selfishness. So, in other words, "we're going to be selfish so that you'll learn how to prevent us from being selfish". That is not at all what you were suggesting about them.
They boldly state that their goal is not only to make a *selfish* client (which is non-optimistic, but could still reciprocate), but actually an *uncooperative* client, that is, it *doesn't upload at all*. At least, that is what the makers say. But what do I know...
said by russotto :2) (and this is the key one) As the number of selfish clients goes up and performance starts to drop, it drops _faster_ for the selfish clients. This means the selfish-client phenomenon is self-limiting. That is a possibility, sure. I was being a little more cautious than that. Let's just hope there is a point of equilibrium like you're suggesting, and the incintive to be selfish does not carry on long enough to kill BT outright. You can't discount the sheer bull-headedness of people, though, when it comes to the "gotta have it now!" syndrome.
said by russotto :When that happens, there will be little incentive for anyone to go back (there would be no potential benefit for an optimistic peer to participate in a selfish swarm, such a peer would just get taken advantage of and gain nothing). On the contrary; on a stream with a few non-selfish peers, the non-selfish peers will communicate parts among themselves much more readily than they will with the selfish ones. Not exactly. You're suggesting the optimistic peers will preferentially unchoke each other instead of unchoking selfish peers. That's only true as long as the optimistic peers reciprocate the best among each other (which is not a given in the scenario). And it also fails to understand what the optimistic unchoke does, which is completely random, and prefers nobody. It is the optimistic unchoke that will be taken advantage of by a selfish swarm. (This may be a little lengthy, but I'll try to give some insight about what exactly the optimistic unchoke does in a BT swarm).
Note that when I say selfish peer, I mean a peer with no optimistic unchokes. The peer may be able to reciprocate, but still be considered selfish if it has no optimistic unchokes. As far as I'm concerned of BitThief, it is both selfish and nonreciprocating, and goes even beyond any assumptions I'm making here about selfish clients in general.
The important factor is that an optimistic client will occasionally upload data to *anyone* chosen at random (10% to 20% of the time in most optimistic clients), to selfish and optimistic peers alike. Optimistic clients unchoke selfishly (based on reciprocation) only up to 80% to 90% of the time but no more. Alternatively, selfish clients propose to unchoke selfishly 100% of the time, leaving no random unchokes available to the swarm (maybe unless there are a surplus of resources available).
The 10% to 20% randomness of optimistic peers would be greatly taken advantage of by a mostly non-reciprocating swarm (peers DON'T HAVE TO RECIPROCATE at all to be selected optimistically!). That just means the selfish peers need only provide up to 80% to 90% reciprocation overall to the optimistic peer for the resources they're taking up (the rest need not be reciprocated), thus, an overall profit for the selfish peer when an optimistic peer is available (provided that everything else is equal).
In other words: The optimistic peers among an otherwise selfish swarm will be working at a loss, while the selfish peers profit. As long as there are more than a critical number of selfish peers in the swarm, the optimistic peers are at a disadvantage.
This is the whole point to designing the selfish client, it is able to take advantage against optimistic clients (not other selfish clients) by taking away more resources than it is asked for in return.
But this does not at all mean we should get rid of optimistic unchokes. They provide too much benefit, when the majority of peers are optimistic.
Consider WHY we have optimistic unchokes in the first place:
If all peers unchoked selfishly (based on reciprocation rates alone) 100% of the time, piece distributions would be less than ideal. Peers who have existed longer and contributed the most to each other would have the majority of the pieces (which may only comprise a small subset of the swarm at worst). Other peers would have little chance to gain any pieces to share at first, even if they would otherwise be good, uploading peers. It would be to an uploaders advantage to provide his pieces to as many peers as possible, so that those peers can start providing pieces to even more peers, and so on, maximizing piece availability in the swarm (which is exactly what BT posits to do) to provide the greatest possible mutual interest (and thus transmission rates) among peers in the swarm.
Now if we instead prefer to upload to a select handful of peers that we know reciprocate the best *only to us*, we may be wasting our bandwidth. A small subset of peers will now have a wide range of *overlapping* piece availability, while the rest of the swarm is ignored until more resources are available. Instead of a peer having 50 sources to download pieces from, there's only 3 or 4 sources that have most of the pieces we want. Upload capacity is not optimized this way, the peers waiting for pieces aren't able to upload very much to others, because the pieces haven't been made available to them yet, even if they are an otherwise strong uploader who could be taken advantage of.
The whole idea of BT is to provide pieces to the widest set of peers as possible taking advantage of all the resources the peers provide. This is mainly accomplished with the small amount of optimistic unchokes. Take away the optimistic unchokes and we might as well be using FTP. | |
russotto
join:2000-10-05
Collegeville, PA
| I've been using "selfish" to mean "non-uploading", not "non-optimistic". BitThief proved that non-uploading clients could succeed in a healthy swarm, but I claim that as the swarm starts to slow down, non-uploading clients will be hurt much more than normal clients, and so the phenomenon will be self-limiting.
I haven't heard of any clients, experimental or otherwise, which provide no optimistic unchoke slots but are otherwise normal. I'm not sure what the advantage is to the user of such a client in a mostly-normal swarm.
It's pretty clear that enough non-optimistic clients will break the swarm, but it's not clear if they are hurt worse than the normal ones as the swarm slows down. I think they are; because they are unwilling to give a part away for free, they are less likely to obtain access to the non-optimistic slots of other clients. But it would take simulations to be sure.
Hmm, thinking about it further, how would a non-optimistic client ever start trading pieces with another non-optimistic client? | |
robo_mojo
join:2006-01-11
Ada, OK
| said by russotto :Hmm, thinking about it further, how would a non-optimistic client ever start trading pieces with another non-optimistic client? The client may unchoke a peer without considering prior reciprocation, only when surplus resources are available (I think I hinted at that somewhere in the earlier post). That isn't the same as an optimistic unchoke, though. It is more like a "forced" unchoke, occuring only when needed, and not necessarily at random. | |
|
