P2P over Tor [was: Anomos - anonBT]

[grarpamp]

> "
> 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