Asynchronous bandwidth limiting

[John Brooks]

First off, thanks for running a node - the network always needs more
bandwidth.

As far as i'm aware, it isn't possible to specify incoming and outgoing
limits separately, and if it were, the outgoing would always be higher. For
the most part, relayed traffic is pretty close to 1:1; for everything that
comes in, there is equal data going out (to the next node in the chain, the
source, or the destination). The one major exception to this is the
directory; requests for the directory are very small, but the results can be
pretty large - but, that just means more outgoing than incoming. There is no
benefit to having more incoming bandwidth than you do outgoing bandwidth.
You can always disable the directory (DirPort 0) if you want to avoid that
little bit of outgoing traffic, but usually it isn't too significant.

Hope that helps.

 - John Brooks


On Tue, Jan 13, 2009 at 2:48 PM, Sebastian Lechte <seb at stian.lechte.net>wrote:

> Hi everyone,
>
>
> I plan to set up a tor node later this week and have been reading
> documentation and different wikis. I have found how I can limit the
> total bandwidth the server will consume.
>
> My hoster only limits outgoing traffic, but as far as I understand, it
> is not possible to specify bandwidth-limits separately for incoming and
> outgoing traffic.
>
> Would it be good to be able to specify limits for outgoing or incoming
> traffic separately, or would that only complicate matters without
> providing any benefit?
> Do incoming and outgoing traffic/bandwidth even differ significantly?
> Does this depend on the type of node and exit-policy (if any) one uses?
>
> I have no experience and have not found specific information on this, so
> I hope that the list members can provide information on this question or
> provide directions for further reading.
>
>
> Sincerely,
>
> S.Lechte
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20090113/849ef06e/attachment.htm>