<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
"""<br>
<pre wrap="">[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
</pre>
"""<br>
<br>
This is the point I was thinking about with respect to exit relays.<br>
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.<br>
Most users don't have that kind of bandwidth, but the wider Tor network
would benefit from more bandwidth in general.<br>
So I assumed, possibly falsely, that some bandwidth given back to the
network is better than none.<br>
<br>
In the case with Torrents, all members of the swarm are usually
supplying the data they have downloaded back to the network.<br>
<br>
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.<br>
<br>
As I noted, the 2GB per day load is beyond most home users, but
thousands of users giving a little bit back could help ?<br>
<br>
Are there any thoughts on this ?<br>
<br>
Regards.<br>
<br>
grarpamp wrote:
<blockquote
cite="mid:AANLkTin=ZJ146fYL4nqG1ds97djisiK_td3YwQLFx4SK@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">"
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.
</pre>
<blockquote type="cite">
<pre wrap="">Am I wrong, Tor Old Ones?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>