BitTorrent.org community
You are not logged in.
Pages: 1
Apologies if I just drop in here, no one here knows who I am, and might seem rude if I jump straight in, but in the interests of expediancy I will just copy+paste something I wrote at another forum. Hope this is helpful in some way. I realize that freeloading may be more conceptual than a current attack, but I hope the following is useful to this forum and P2P overall.
Some background on me (not relevant, share to get familiar with me):
http://www.coolpagehelp.com/developer.html#2
http://www.w3.org/TR/CSS21/about.html#acknowledgements ("Shelby Moore")
http://www.google.com/search?hl=en& … tnG=Search
http://bugs.activestate.com/buglist.cgi … alue0-0-0=
http://www.coolpage.com/commentary/econ … rning.html (an email that was never sent)
http://www.coolpage.com/commentary/econ … ation.html
http://financialsense.com/fsu/contribut … helbymoore
shelby at jasonhommelforums.com/forums in "How to beat Google?" wrote:
Okay this hack of BitTorrent:
http://dcg.ethz.ch/publications/hotnets06.pdf
demonstrates what Jason Hommel and I had decided in 2006, which is that P2P can only work if there are micro-payments system using a real money...
1) I have an idea for an improvement for BitTorrent's protocol, which I think will block the above "freeloading" vulnerability.
Freeloading is possible in BitTorrent because fundamentally all P2P (peer-to-peer) involves a trade (share) of data. As each chunk of a file is traded, one peer has to go first and trust that the other peer will reciprocate.
There is nothing in the fundamental protocol of the internet (TCP/IP or UDP) that enables two peers to guarantee both peers will send and assure mutual receipt. In fact, it would not be possible, because the routers implementing the internet protocols are themselves peers, and thus could void any such guarantee. The internet is robust precisely because the fundamental protocols can handle high rates of failure (packet loss).
Peers may fail to reciprocate due to network issues, but this is not a vulnerability, rather just a normal requirement for robust load balancing. Also peers might contain programming errors, but the motivation would be to fix these over time (one would assume the most popular clients would fit the motivation of the market). Thus, other than an intent to be malicious, the only possible reason a peer would not reciprocate, is the economic cost of reciprocating (of uploading it's chunk of the file).
My idea is peers then trade an encrypted file chunk, then acknowledge receipt by trading the decryption strings. Thus, no peer has a bandwidth economic motivation to not trade the file chunks, as before they can use the chunk they received, they must send an equal size chunk. The decryption strings are so small relative to the file chunks, that the peers have no bandwidth economic motivation to not trade them.
I do not know if this has already been proposed else where?
2) So the above idea, removes the need for money (micro-payments) in the case where like-files are being traded (i.e. in the BitTorrent type of swarm P2P).
3) The above idea does not stop malicious vulnerabilities, motivated by external economics. I will be addressing this in a future post.
=========================================
Why BitTorrent is important & implications of "malicious"
=========================================
Many people probably associate P2P with illegal activities, e.g. sharing copyrighted data.
However, P2P (peer-to-peer) will be incredibly economically important for the internet to grow at it's maximum possible exponential growth rate.
The current C/S (client-server) method of internet publishing, places the upload cost on the publisher, not on the consumer. This has proliferated the advertising business model (i.e. in one word "Google"), in order for the publisher to recapture the upload cost. This places economy-of-scale hurdles (granularity limits) on publishing. This is a centralization creep paradigm due to the motivation of economy-of-scale, which conflicts with the paradigm of exponential disordered growth via the 0 cost hyperlink, which forms the basis of the WWW (world wide web).
In short, the Entropy of the universe is trending to maximum, the 0 cost hyperlink is a radical mass-busting (Entropy accelerating) paradigm, but the economy-of-scale economic paradigm of C/S will work against diffusion of mass (free market). Realize that I have shown else where that knowledge is gained by the free market as the number of actors and interactions increases (i.e. as the Entropy increases):
http://www.coolpage.com/commentary/econ … lence.html
The problem of upload cost applies when a file is popular. BitTorrent is a form of P2P that focuses on sharing like-files, where since there are many downloaders of the same file, then the downloaders can also be the uploaders. Thus the upload cost is shared by the downloaders, and not a cost of the publisher.
Afaik, up to now no one had solved the problem of potential freeloading vulnerabilities on P2P. I had reached the theoretical conclusion after deep study in 2006 that no open P2P network could prevent bandwidth economically motivated freeloading, unless it used some form of real money micro-payments. And I do not think users would ever agree to be prompted for micro-payment confirmation every time they click a download link. However, when trading chunks of the same file, the data itself is common money, but the problem remained how to guarantee the escrow, so trade is completed by both peers. I think I have now solved that issue as detailed above.
However, I can see no way for the P2P protocol to prevent malicious intent. Fortunately, I do not think malicious intent is a viable threat, because clients are motivated to defend their network. Usually in society, this means that most people choose to use an "obedient" client, because absent a selfish economic benefit, then Pareto Efficiency applies:
http://www.bittorrent.org/bittorrentecon.pdf
(see section 3.1 on page 4)
Pareto Efficiency explains why only about 2.5% of the population is criminal.
Even if the entire society became criminal, then a sub-society could form it's own private P2P network using the same protocols, such as by using a secure username and password with a credit card for identification on signup. However, I do not think such private networks will be required, because society as a whole is Pareto Efficient.
Last edited by shelby (2008-04-29 12:46:23)
Offline
I'd appreciate if you'd be more concise and less philosophical. I'm also not quite sure if you understand how bittorrent works. Bittorrent already does enforce reciprocity where it is necessary, i.e. when there is no surplus of bandwidth. In a swarm w/o seeds (i.e. only peers) the unchoking alogrithms will punish freeriding significantly and fast uploaders will download faster. Freeriding is only possible when there's a surplus of bandwidth, which means it's less of an issue (although still an annoyance).
You also used a rather old implementation (the python mainline client), more advanced clients are more sophisticated when it comes to their swarm behavior, so i suggest you retest with Azureus or µTorrent. And if you compare uploading vs. not-uploading you also have to consider that uncapped upload will lead to worse TCP performance, that's why the general advise is to upload at ~80% of the line's upload capacity.
And assuming you have a fast line then clients also need tweaking of various settings, including upload slots. So i'd say your comparison is not entirely practical.
Oh, and you also said that TCP overhead would be significant for 500 connections or so... nobody claims that. the HAVE messages combined with TCP overhead are the issue.
Ah, i finally found the point of your post, and yes... this has been proposed before:
My idea is peers then trade an encrypted file chunk, then acknowledge receipt by trading the decryption strings. Thus, no peer has a bandwidth economic motivation to not trade the file chunks, as before they can use the chunk they received, they must send an equal size chunk. The decryption strings are so small relative to the file chunks, that the peers have no bandwidth economic motivation to not trade them.
This comes down to a block based tit-for-tat instead of rate based tit-for-tat, something that has been tried in the past (one of the earliest python bittorrent clients) but worked horribly and thus was dropped. And i don't see how it would solve the seed/optimistic unchoke freeriding.
Last edited by The 8472 (2008-04-29 13:34:59)
Offline
Thanks for reading.
Rather than use only a systemic goal of upload bandwidth as a limit, noting that I've read in your forums that in general unbalanced upload usage is causing throttling by ISPs such as Comcast, I am proposing that you can specifically incentivize reciprocity on each exchange of data with a fairly straightforward change to the protocol as follows. I realize this would require all clients to change, or maybe this idea can be used for a new competitor to BitTorrent's protocol:
My idea is peers then trade an encrypted file chunk, then acknowledge receipt by trading the decryption strings. Thus, no peer has a bandwidth economic motivation to not trade the file chunks, as before they can use the chunk they received, they must send an equal size chunk. The decryption strings are so small relative to the file chunks, that the peers have no bandwidth economic motivation to not trade them.
Also note that I view that systemic choking as vulnerable as long as there is an economic incentive to not upload on each exchange of a file chunk. You really won't know how vulnerable it is until you get mainstream commercial usage and there is enough incentive for rogue clients to emerge in popularity. If there is no economic incentive, then Pareto Efficiency concludes that rogue clients won't achieve popularity.
Apologies if I am missed something important, and I will note your clarification if I so agree.
Btw, my interest in this is because I would like to see BitTorrent-like protocol eventually enabled for all links on the WWW, via a browser plugin. This is something I would like to see for a highly disordered project I am developing to compete with OpenSocial, MySpace, FaceBook, etc.. This will hopefully be my encore to my CoolPage.com.
Oh I see you were editing your post while I was replying:
This comes down to a block based tit-for-tat instead of rate based tit-for-tat, something that has been tried in the past (one of the earliest python bittorrent clients) but worked horribly and thus was dropped. And i don't see how it would solve the seed/optimistic unchoke freeriding.
Could you point me to a resource which discusses this in more detail. What was the context, what didn't work, why didn't it work, etc? I mean I am not proposing to do any choking based on a failure of the block based. Maybe that is why it gave horrible performance in the past, because you made larger rate decisions based on the block. The block tit-for-tat needs to be a local outcome and not extrapolated out beyond local.
It meres closes the economic motivation loophole.
Think of the block tit-for-tat as analgous to packet loss.
Last edited by shelby (2008-04-29 13:48:25)
Offline
I am proposing that you can specifically incentivize reciprocity
I don't see how rate based TfT doesn't do that.
Also note that I view that systemic choking as vulnerable as long as there is an economic incentive to not upload on each exchange of a file chunk.
Please explain why you think so. All freeriding on bittorrent happens due to optimistic unchokes and seeds and not due to the non-optimistic chokes. If you're saying we should remove optimistic unchokes then this is not practical since we have to randomly try peers to see if the reciprocate. block based reciprocation would also leave bandwidth unused in case a peer with a fast upload could not find his equals. Optimistic unchokes are also necessary to randomize the global set of active connections and provide initial data to peers w/o explicitly providing data to peers that appear to be new, pieceless peers, otherwise one could exploit generosity towards new peers by not signaling any pieces.
Could you point me to a resource which discusses this in more detail. What was the context, what didn't work, why didn't it work, etc?
No, this was discussed on IRC a while ago and i barely remember it, ofc nobody writes whitepapers based on IRC discussions. And as i said, this was done in the earliest versions, so it's basically ancient history now.
Offline
block based reciprocation would also leave bandwidth unused in case a peer with a fast upload could not find his equals
Afaics, block based reciprocation should be (is) orthogonal to systemic bandwidth optimization (i.e. choking algorithms). You should not make any choking decisions based on block based reciprocation. The block based reciprocation can operate entirely orthogonal to your existing algorithms. So I do not see how it can interfere with optimistic unchoking?
I proposed that both peers receive an encrypted copy of the chunk, then they both acknowledge receipt by sending the decryption keys. This simply removes the incentive to not upload. By not uploading, the peer can not decrypt the chunk it stole.
I am guessing that the reason you saw horrible results with block based reciprocation in the "ancient history" was because you did not have the systemic choking. You need both. They are orthogonal and serve different purposes. I suspect that in "ancient history" you were trying to do some form of (even simplistic) systemic bandwidth optimization based on the block reciprocation results, and imho that would be horrible. The block reciprocation is simply a local motivation (a carrot), and not statistical metric to feed into a systemic algorithm.
You seem to pondering what is the advantage. The advantage is it removes the upload bandwidth cost motivation to not upload. Because peers can not get any chunk if they do not upload. But this does not block optimistic unchoking at all. Optimistic unchoking is about selecting a peer to try. Block reciprocation has nothing to do with selecting a peer, it only has to do with how the escrow between chosen peers is performed. Choking algorithms sit at a higher systemic level than block escrow.
I am not ignoring the other points in your post, but let me first reply with this line of logic, to see if we are on the same page or where we differ, before we dig into other points made.
---Add---
This improvement I think would become even more important if a BitTorrent-like protocol was used on extremely popular, smaller files. Imagine something like Google Gadgets could be stored any where, not just on Google's servers. Small publishers are forced to use Google's API, because they don't want to host their own 1 million times downloaded gadget file.
With small files, I think the block reciprocation will be critical, as the systemic choking algorithms will not get enough samples (file chunks) per peer to be statistically effective. One might be able to extend the systemic to cross file data, yet the block reciprocation is straightforward and deterministic.
Even on large files, I think the block reciprocation closes the bandwidth economic motivation to not upload, otherwise this may eventually open the network to some sort of bandwidth economically motivated attack. We could dig deeper into these hypothetical vulnerabilities, or lack thereof.
Last edited by shelby (2008-04-29 15:17:54)
Offline
Are you talking about the motivation to cheat in a game of repeated tit-for-tat? Assuming I don't know when the repeated game will end, I gain an indefinite long term benefit from continuing the game. Theory says reciprocation should occur, and in this case theory matches practice.
Block-based tit-for-tat was the first thing Bram Cohen tried. It had the problem that it didn't make use of all available capacity when there is even a slight rate mismatch. Rate-based tit-for-tat makes use of all available capacity and is thus more efficient at the expense of allowing some asymmetry in the amount traded.
Offline
Block-based tit-for-tat was the first thing Bram Cohen tried. It had the problem that it didn't make use of all available capacity when there is even a slight rate mismatch. Rate-based tit-for-tat makes use of all available capacity and is thus more efficient at the expense of allowing some asymmetry in the amount traded.
Afacis, block reciprocation has nothing to do with capacity utilization optimization. You need your existing (choking) systemic rate optimization to do capacity utilization optimization. So that explains why block reciprocation didn't do what it isn't supposed to do.
Afaics, the specific block reciprocation algorithm that I have proposed, can co-exist with the current choking rate optimization. The benefit should be that freeloaders will entirely cease to exist (even in all potential future conceptual attacks). The only remaining attacks will be programming errors or those maliciously motivated.
Are you talking about the motivation to cheat in a game of repeated tit-for-tat? Assuming I don't know when the repeated game will end, I gain an indefinite long term benefit from continuing the game. Theory says reciprocation should occur, and in this case theory matches practice.
I may be missing your point. I am saying that a freeloader can wait for optimistic unchokes and never reciprocate. If there are enough peers to choose from, the freeloader can get the entire file without reciprocating, because the peers will not be able to detect and ban the freeloader with the current choking algorithms. And it is counterproductive to worry with banning or detecting this case, when one can simply eliminate it by implementing my proposal which can co-exist with choking. Afaics, my proposal will have no adverse effect on the existing choking algorithms.
So how did you benefit from continuing the game, if the plurality of rogue clients freeloaded and rendered your down/up bandwidth asymmetric? Is your "practice" so far in a fairly sterile testbed? What is wrong with my proposal for attaining both rate optimization and symmetry of reciprocation?
Tangentially, I am also saying that for a very small file (imagine a file that is 1 chunk in size), my proposal is even more critically needed. I realize that is not the main intent of BitTorrent now, and it is not my main point herein. It will be important if I succeed in applying a BitTorrent-like protocol to small files in future.
Last edited by shelby (2008-04-29 19:37:50)
Offline
You seem to pondering what is the advantage. The advantage is it removes the upload bandwidth cost motivation to not upload. Because peers can not get any chunk if they do not upload. But this does not block optimistic unchoking at all. Optimistic unchoking is about selecting a peer to try. Block reciprocation has nothing to do with selecting a peer, it only has to do with how the escrow between chosen peers is performed. Choking algorithms sit at a higher systemic level than block escrow.
If that's your goal it basically comes down to the optimistic unchokes as normal unchokes are per definition already reciprocated. And that means that we'd not give the key for the encrypted block to a user whenever he does not reciprocate on an optimistic unchoke. This in turn means we waste upload bandwidth, with a 3+1 upload slot rule we might waste up to 25% of our upload bandwidth as the other peers will not reciprocate since you're uploading slower than all current unchokes they get.
Please remember that it's always the current N-M fastest peers out of N upload slots (where M = 1 or M = a constant fraction of N, depending on implementation) will get unchoked. Thus optimistic unchokes that go to peers we know nothing about might never be reciprocated since we are uploading slower than their N-M fastest peers.
Another problem is the distribution of pieces, in a low-availability state it's more important to get pieces you have out there than ensuring 100% fairness. As long as a peer does not freeride completely but merely is somewhat slow when it comes to uploading (and thus won't reciprocate to you immediately) it'll be better to let him have the piece than refusing the key and thus lowering the swarm-wide availability.
Then there also are implementation-issues... like timing out key-messages since we'd stall pieces otherwise if a peer sends encrypted blocks but not the key.
So to repeat my question: Where exactly in bittorrent do you see the benefit of this behavior.
Last edited by The 8472 (2008-04-30 11:56:34)
Offline
normal unchokes are per definition already reciprocated
Neither word "encrypt" nor "decrypt" appears in the specification:
http://www.bittorrent.org/beps/bep_0003.html
Thus, I conclude the specification contains no block-level reciprocation, using decryption keys, as I have proposed.
I await your clarification before delving into your other points. Thank you.
---Add---
I still need a clarification on the above regarding normal unchokes. Decided to address this point now:
...means that we'd not give the key for the encrypted block to a user whenever he does not reciprocate on an optimistic unchoke. This in turn means we waste upload bandwidth...as the other peers will not reciprocate since you're uploading slower than all current unchokes they get...
...problem is the distribution of pieces, in a low-availability state it's more important to get pieces you have out there than ensuring 100% fairness. As long as a peer does not freeride completely but merely is somewhat slow when it comes to uploading (and thus won't reciprocate to you immediately) it'll be better to let him have the piece than refusing the key and thus lowering the swarm-wide availability.
You've made a design decision to sacrifice symmetric up/download bandwidth, to enable saturation of the upload bandwidth of each peer. No wonder the ISPs are throttling BitTorrent protocol.
Peers should back off their upload bandwidth to leave some margin for reciprocating to optimistic unchokes, as it is in their (and the network's, i.e. Pareto Efficiency) interest to discover new peers. To say we need to saturate the upload bandwidth, and thus we need to create dishonest (unfair) money, will drive the BitTorrent protocol to failure as it becomes more popular. Let me explain why.
<start philosophical teaching>
Jason Hommel taught me a universal economic principle, "you can't give away something free which is not free". Thus, sacrificing "100% fairness" is equivalent to transferring the economic cost of unfairness to the ISP's bottom line. The ISP then has to either make all non-BitTorrent users pay (socialism), or try to throttle the offending BitTorrent users. In effect, the "generosity" of asymmetry is analogous to the theft of dishonest weights & measures, with a dilution of the real value of the money (the data) being traded. It is analogous to using debt (fiat money) to pump up an economy to saturation. The side effect is mis-allocation of capital (the capital is the upload bandwidth of all users on the ISP, not just the BitTorrent users).
It is dangerous (to the future of society and the internet) when programmers play the role of economists, and do not have a good understanding of non-keynesian fundamental truths. Guys I am 42, been a personal computer programmer for 26+ years (since Atari 800, Commodore 64, 8088 & 6800 assembler code, etc), as programmers of key paradigm shifts on the internet, the economic ramifications of our work is much more important than the "coolness". And I am still very much into "coolness", as I own the domain CoolPage.com. Let me help you guys on the economics, you are obviously talented on the "coolness". Socialism fails and causes misery. Open source is not necessarily socialism. Let's stay focused on the absolute power of the free market and thus the critical element of integrity of honest weights & measures. Without economic integrity, networks (societies) devolve into morass.
This boils down to choice between socialism (keynesian "capitalism") or libertarianism (free market/mises capitalism). The latter choice always wins in the long-run.
</end teaching>
If BitTorrent isn't fixed, then someone else (me?) will create a protocol with 100% fairness. The free market and integrity can not be denied in the long-run.
Last edited by shelby (2008-05-01 01:37:26)
Offline
i will only say this once again: Make more concise posts and leave the philosophical stuff out, we do not care. And i neither claimed that there would be any block-encryption nor did i say that there would be block-level reciprocation. I only said that unchokes are by definition reciprocated. Since you did not understand that i have to assume an insufficient understanding on how bittorrent works on your end, thus i'll wait until you understood it before continuing the argument.
You've made a design decision to sacrifice symmetric up/download bandwidth, to enable saturation of the upload bandwidth of each peer. No wonder the ISPs are throttling BitTorrent protocol.
This argument is also bogus, as the global sum of uploaded = downloaded. Thus ISPs would throttle anyway, as adjusting fairness would just shift the required upload bandwidth somewhere else.
Offline
Now we cut straight to the end-game of this discussion.
...leave the philosophical stuff out, we do not care...
I can not leave out the economics. Any engineer who ignores economics, will fail.
I am designing a superior economic protocol based on this exchange. I won't need you, but I am willing to work with you, to achieve maximum specialization of labor. I am friendly, to those who reciprocate in kind.
...Since you did not understand that i have to assume...
Ad hominem attacks are a pattern of failure. I understood that you were making the following critical error in your assumptions.
This argument is also bogus, as the global sum of uploaded = downloaded. Thus ISPs would throttle anyway, as adjusting fairness would just shift the required upload bandwidth somewhere else
False.
ISP's bottom line results from their users, not the global sum that involves other ISPs. Your economic design flaw penalizes ISPs (and all their non-BitTorrent users) who offer a higher upload-to-download bandwidth ratio than other ISPs.
In short, your line of logic is socialistic economics, which is a failure oriented economic system. "To each according to his need, from those according to their abilities". How much obvious I can be?
...This in turn means we waste upload bandwidth...
"waste" is an economic oxymoron in that context. The current protocol's design goal is to maximize global upload = download bandwidth, but this sacrifices individual fairness for the "good" of the entire group. This creates socialist mis-allocation of capital, which is economic "waste". Thus "good" ends up as failure (e.g. throttling, and parasitic freeloading attacks that will come in future). Socialism economically motivates failure, because it encourages those who do less. In case of current protocol, it will be motivating the use of ISPs which give a lower upload-to-download bandwidth ratio, in order to parasite on ISPs who give a higher ratio.
...i neither claimed that there would be any block-encryption nor did i say that there would be block-level reciprocation...
I know you didn't specify "block", which is why I pointed it out in my reply. You see the fundamental concept of non-socialist economic paradigms, is no futures contracts. The economic exchange must be as granular and immediate as possible.
Again I extend my offer to help you "guys". Or I can go around you. Makes no difference to me. It is an offer only, not a demand or a force. The free market is the force you have to contend with.
Offline
So you say it's economical to waste resources that could be utilized otherwise? And people wonder why we have pollution and global warming.... See, we as engineers/programmers think about efficiency, and the current approach is more efficient than what you're proposing.
And i won't get into the "free market vs. socialism"-debate, as this would only downspiral further.
And btw, it was not a ad hominem attack, i simply pointed out what you said yourself, you wanted clarification for something which i already said is defined by the protocol itself. Thus you did and do not understand the protocol or interpreted my words instead of taking them literal as they were meant.
Just to make this clear again: Bittorrent already ensures fairness when it is necessary.
Oh, and something to read for you: the iterated prisoners dilemma.
Last edited by The 8472 (2008-05-01 06:35:04)
Offline
So you say it's economical to waste resources that could be utilized otherwise?
The resources are not free. Someone has to pay. The question is who pays? It should be the user who is using the resources that pays, but BT's design defeats that correct economic paradigm. Asymmetrically giving upload bandwidth from one ISP to another ISP is theft. The ISP which is being stolen from, will throttle, so their non-BT users do not have to pay more $ to subsidize the BT users who are giving away the asymmetric upload bandwidth.
The solution is to make sure that tit-for-tat is enforced at the user level (each P2P block reciprocation), not on the global scale. Each peer should optimize the network in his best interest, according to Pareto Efficiency.
Oh, and something to read for you: the iterated prisoners dilemma.
BT's protocol is not following the best case:
"best deterministic strategy was found to be Tit for Tat',...is simply to cooperate on the first iteration of the game; after that, the player does what his opponent did on the previous move...a slightly better strategy can be 'Tit for Tat with forgiveness'. When the opponent defects, on the next move, the player sometimes cooperates anyway, with a small probability (around 1%-5%)...".
My proposed block-level encrytion 'tit-for-tat', coupled with a better systemic optimization algorithm, would better implement the best case, including the 'forgiveness' without going asymmetric.
Afaics, the best systemic optimization would be random selection of peers into a queue, with block-reciprocated peers re-placed into queue after each reciprocation. First come, first serve, with the queue dominated by cooperating peers, but just enough new random ones to offer 'forgiveness'. The queue would solve the problem of locking out random peers when upload channel is saturated. The latency issue (BT queues up multiple sends also) would be inherently a non-problem due to queuing up many peers, with replies arriving on a first-come, first-serve basis. If a peer does not have enough upload capacity, then it is inherently scaled down in the network because that peer takes longer to reply. This would be a much simpler protocol as well. I think it would need to run on UDP, not TCP, and I am studying that now.
...people wonder why we have pollution and global warming...i won't get into the "free market vs. socialism"-debate, as this would only downspiral further...
If one zooms in on Gore's charts, C02 lags temperature rise by 800 years. Temperature rise causes C02 rise, not vice-versa. The oceans release million times more C02 when warmed than people do. But it takes 800 years for the miles deep (not surface) ocean temperature to warm up. Temperature rises are caused by the sun. We are actually entered a cooling phase.
http://www.global-warming-myths.com/ima … tivity.jpg
http://www.john-daly.com/press/lag-time.gif
http://www.google.com/search?hl=en& … gle+Search
You could learn a lot from me. And I bet I could learn a few new tricks from you also. Friends or competitors we will be? The free market needs both, so makes no difference to me.
---Add---
Also thank you very much for the discussion. You have helped me confirm my understanding of BT's weakness. And helped confirm my understanding of direction forward. I do sincerely appreciate your time. I hope in some small way, down the line, this discussion will be proven to have been a help to you.
---Add #2---
Note that my proposal means that each peer will not be able to download faster than the peer's upload bandwidth. This respects the economic reality that ISPs operate within. Peers who want to download faster, thus need to pay their ISP for more symmetric upload-to-download bandwidth ratio. The cost is paid by each peer according to that peer's needs and useage.
Last edited by shelby (2008-05-01 15:20:23)
Offline
Shelby,
If I understand correctly you are trying to limit the damage of peers that download only by exploiting optimistic unchokes. Encryption is used to guarantee that a peer uploads a block's worth of "something" before the user can make use of a block's worth of something he or she has downloaded. 1) A malicious user could make use of optimistic unchoke to simply consume bandwidth from the swarm. 2) Or a malicious user could wait until provided the key and not return a valid key. However, in the first case, the malicious user derives no benefit from what has been downloaded. In the second case, the user derives benefit from what has been downloaded but must consume uplink capacity to get the key and thus the second form of cheating is not free. In either case, a non-malicious user (i.e., motivated only to maximize his or her utility) would upload. This is your proposal. No?
This is indeed orthogonal to rate-based tit-for-tat. All of the existing mechanisms could be retained. Every so often each pair of players could exchange keys up to the number of blocks that have been reciprocated. For example, if A has sent 20 blocks to B while B has sent 10 blocks to A then both exchange 10 keys. Is this what you are proposing?
My Comments
Assumption: user utility is an increasing function of download rate.
Without your proposed mechanism, each non-malicious user is still motivated to send as fast as possible (at least in the absence of knowledge of how fast other peers are sending*), since sending faster increases the probability of staying within the neighboring peer's unchoked set.
What you are proposing does provide a strict improvement in the case for users that derive maximal utility from not sending, and this would be the case for anyone forced into usage-based billing for uplink capacity where the usage price is higher than the value derived from downloading faster.
If my assessment of your proposal is correct then this has little value in the United States. It however might be valuable in other countries. Despite the belief of many Americans, the Internet does span the entire globe and so I defer to the assessment of those outside the United States.
* Aside: The qualification of "absence of knowledge" is necessary because if a peer knows how fast other peers are sending then he or she need only send fast enough to stay within the unchoked set. Knowledge of this kind is exploited by BitTyrant, but that is a different problem.
Offline
Your astute restatement of my proposed algorithm appears to accurate and easy-to-understand, with one exception. I did not propose the bulk exchange of keys, but that may not be (for future contemplation) a central issue to the algorithm. You also astutely stated that non-malicious users would lose economic incentive to not upload. Also note that my proposal is "economically complete" in simplicity, meaning there are no economically motivated loopholes, such as the BitTyrant exploit of the "unchoking" which you mentioned.
Thus BitTorrent's systemic "unchoking" algorithm becomes unnecessary, unless one assumes there is a beneficial optimization from asymmetric down/upload bandwidth per peer and/or per ISP.
What you are proposing does provide a strict improvement in the case for users that derive maximal utility from not sending, and this would be the case for anyone forced into usage-based billing for uplink capacity where the usage price is higher than the value derived from downloading faster.
If my assessment of your proposal is correct then this has little value in the United States. It however might be valuable in other countries.
My understanding is the "unchoking" algorithm attempts to maximize global bandwidth, with download = upload globally, but this comes at the cost of asymmetric down/upload bandwidth per peer and/or per ISP.
It appears your assumption is that flat rate billing implies that upload and download costs are symmetric. Let me explain how my logic is derived from "usage price is higher than the value derived from downloading faster".
With flat rate billing, the user is motivated to download up to his download bandwidth limit. The user pays nothing extra for the upload bandwidth. If the ISP has priced their flat rate service based on the predominant C/S (non-P2P) model of the internet, then the ISP may be assuming a global say 10% upload-to-download bandwidth ratio. If the network does not behave according to the pricing model of the ISP, then the ISP will either have to absorb the economic losses, modify the pricing, or throttle the offending network traffic.
Thus, I think my proposal applies in the United States and every where, irregardless if the user is currently billed for upload bandwidth. Just because a cost is hidden behind flat rate pricing, does not mean the cost does not exist.
Asymmetric down/upload bandwidth per peer means that ISPs which offer more flat rate upload bandwidth, will be subsidizing those ISPs which offer less flat rate upload bandwidth. So "unchoking" will economically force the upload cost to be priced out to the user over time, and thus in the end you will either get symmetric networks or you will get severe throttling. Over the long-term, there is no way to avoid the free market effect that everyone must ultimately pay for the costs they use.
My understanding is the underlying cost of full-duplex communications, means that the upload uses a portion of the frequency band of the wire, and thus upload is not free:
http://en.wikipedia.org/wiki/Duplex_(te … ion_duplex
---Add---
Assumption: user utility is an increasing function of download rate.
Without your proposed mechanism, each non-malicious user is still motivated to send as fast as possible (at least in the absence of knowledge of how fast other peers are sending*), since sending faster increases the probability of staying within the neighboring peer's unchoked set
I implied the following, but let me make it explicit.
Although the user is motivated to download at his maximum download speed, the ISP has an economic motivation to limit the peer's upload capacity to the predominant pricing model, thus the peer has no choice but to leech on "optimistic unchokes" and the network ends up asymmetric. This economic motivation is a form of socialism, where everyone loses over the long-term, as more ISPs will be motivated to throttle to their pricing model, because of the "unchoking" which desires to maximize global leeching to "share costs" and not have the costs paid by those who need the extra speed.
---Add #2---
Clients could do "optimistic unchoking" in my proposed protocol, by simply sending the key even if they did not receive the reciprocated data. So the free market could decide which type of client is the winner. The protocol should be agnostic and maximally generalized.
---Add #3---
ISPs beginning to monetize excessive bandwidth useage that deviates significantly from their per-user average bandwidth cost business model:
http://bits.blogs.nytimes.com/2008/05/0 … th-limits/
Last edited by shelby (2008-05-10 09:26:02)
Offline
Pages: 1
