P2P over Tor [was: Anomos - anonBT]

Cav cav at gotadsl.co.uk
Wed Nov 17 23:48:55 UTC 2010


"""

[3] As the average bandwidth that most users [dsl, cable] will be
able to give back is small, transfers will be slow anyways. Which
may limit adoption [P2P peer counts]. Regardless, the limiting
factor is really only bandwidth because (dice up the giveback/6 you
can legitimately use... amongst P2P peer circuits however you want,
ie): dsl/cable = 1 x 256Kb/6 = 10 x 25.6Kb/6 = 100 x 2.56Kb/6

"""

This is the point I was thinking about with respect to exit relays.
It has been noted that 2GB per day is the load that an exit relay ought 
to handling, to be of use the Tor network.
Most users don't have that kind of bandwidth, but the wider Tor network 
would benefit from more bandwidth in general.
So I assumed, possibly falsely, that some bandwidth given back to the 
network is better than none.

In the case with Torrents, all members of the swarm are usually 
supplying the data they have downloaded back to the network.

This leaves me wondering if these kinds of p2p principles can be brought 
to bear on the Tor network too, with users offering what they can, when 
they can, back to the Tor network.

As I noted, the 2GB per day load is beyond most home users, but 
thousands of users giving a little bit back could help ?

Are there any thoughts on this ?

Regards.

grarpamp wrote:
>> "
>> It's my understanding that BitTorrent is less of a bandwidth hog as it
>> is a connections/circuits hog. These are expensive to create and you
>> can't balance your BitTorrenting by hosting a high-bandwidth node
>> because to have 0 net effect on the network, you'd have to host a
>> circuit's worth of nodes for every circuit you're using for BitTorrent
>> connections.
>> "
>>
>> Bandwidth is surely finite but I'd bet safe to calculate. I would think
>> it easy to reach zero net, starting at minimally six times your use.
>>
>> Circuits are a separate issue. AFAIK, they are just consumers of state
>> on the nodes... CPU, RAM, TCP, etc. I can see where adding a node
>> [any node] in at 6x [or any x] would help distribute that load as well.
>>
>> Other than between the tracker, BT spawns a bunch of bandwith filled
>> pipes, up to some number of peers limit in the app. What is, if any, the
>> relationship between IPv4 TCP flows and Tor circuit usage? That could
>> help calculate the replacement value for non-bandwidth node resources.
>>
>>     
>>> Am I wrong, Tor Old Ones?
>>>       
>> I sure haven't got that far in reading to guess yet, so yeah, if someone
>> has a hunch, that would be interesting. Maybe 6 nodes that add up to
>> 6x bandwidth or something.
>>
>> Not sure about anyone else, but I do think that with the way things
>> are going on the internet, more people will be looking to anonymous
>> systems in general to supplant it for their 'filesharing' and other
>> interests. That accumulation might be unstoppable.  So hopefully
>> those sorts of uses are being thought after and researched/planned/coded
>> for.
>>     
>
>
> Thought about the non-bandwidth parts of the load some more...
>
> There doesn't seem to be a need to quantify it with a numerical
> estimate of what amount of resource giveback would yield a zero sum
> impact for those parts.
>
> Say you're using 'filesharing' in the form of BitTorrent. Your
> single PC, when operating as a non-exit relay [1], can surely handle
> many times the trivial sum of all the various non-bandwidth resources
> described above that you would use along the way. Think of simulating
> a TorNet by running all the needed directories, nodes and operations
> bound to IP aliases on one PC. Conservatively say [3] you will have
> up to 100 P2P circuits at 6 hops each... Any PC should be able to
> handle that entire load with lots of headroom.
>
> So long as users are covering their bandwidth with giveback [1], I
> think it's safe to assume the rest of their overhead is also covered
> by the addition of that node to the network.
>
> I no longer think the standard reply/FAQ regarding such uses of
> Tor, excepting [2], should be an unqualified: Tor can't handle it,
> so don't.
>
> The answer should be that... so long as such giveback [1] is:
> - understood by users to be a necessary 'techical' condition to
>  support their use of Tor for bulk transfer.
> - indeed provided back to the network as a 'moral' condition by
>  those same users.
>
> ... they should then feel free to use Tor for whatever they want.
> BitTorrent, P2P, FTP, streaming media, chat, etc. And OnionCat is
> the shim that will allow the apps to communicate seamlessly.
>
> Though not as simple a response, and requiring donation by the user,
> it seems to be the more reasoned one.
>
> Further thoughts welcomed.
>
>
> [1] It's already established that in order for your use of Tor
> bandwidth to be zero sum (in the Hidden Service <--> Hidden Service
> case) you need to give back at least 6x your use. So you will already
> be running said relay (for the purpose of bandwidth giveback).
>
> [2] Isn't there a proposal out there to better handle magnitudes
> more users [and avoid shutdown points] by getting rid of the
> directories and self-hosting the TorNet into a DHT or something?
>
> [3] As the average bandwidth that most users [dsl, cable] will be
> able to give back is small, transfers will be slow anyways. Which
> may limit adoption [P2P peer counts]. Regardless, the limiting
> factor is really only bandwidth because (dice up the giveback/6 you
> can legitimately use... amongst P2P peer circuits however you want,
> ie): dsl/cable = 1 x 256Kb/6 = 10 x 25.6Kb/6 = 100 x 2.56Kb/6
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20101117/e19ac8e1/attachment.htm>


More information about the tor-dev mailing list