Re: Bittorrent

[Martin Fick <mogulguy@xxxxxxxxx>]

> >If you are really creative (and desperate,) ;) you 
> >could probably already achieve port rate limiting
> >by just running several exit nodes with different 
> >exit policies and bandwidths.  And prioritization 
> >and rate limiting could probably both be achieved 
> >by adjusting the bandwith and CPU of the 
> >nodes with some OS parameters, i.e. nice+20 for 
> >CPU and other mechanisms for network usage.

--- On Wed, 2/18/09, Scott Bennett <bennett@xxxxxxxxxx> wrote:

>    But this last looks to me like a really bad idea for
> at least two reasons.  One is that exits are also 
> middle relays and sometimes entry points or even 
> entry guards into the tor network.  Biasing
> the scheduling of tor toward lower dispatch priorities 
> affects everything that tor does, not just exit 
> operations.  Secondly, if tor is sharing a busy system, a
> reduced priority could well lead to timeouts for many of
> tor's activities that would result in additional 
> retries and/or failures that would not
> otherwise have occurred.

--- On Wed, 2/18/09, tor-operator@xxxxxxxxxxxxx <tor-operator@xxxxxxxxxxxxx> wrote:
> It is an open question whether or not doing this is a nice
> thing to do, particularly since it would not be "advertised"
> to the TOR process on said box.


Agreed, both valid criticisms.  All the more reason to add 
this to the exit policy so that it is not "circumvented"
the way I suggested! ;)

But do you see any reason that this applies to the 
non OS tricks solution of simply having two exit 
nodes with different policies solution that I suggested?

If we are to assume that both nodes would actually be 
running on the same host, the limited bandwidth to the 
'evil' port exit node would not (noticeably) inhibit 
the overall tor middle node bandwidth (versus the single 
exit alternative) since the other peer would be assumed 
to provide enough middle node bandwidth, right?  And,
there would be no "cheating" of service reporting then 
either?


I have to note though, that the FAQ:

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#RunARelayBut

suggests something slightly like this already:

  "5.17. What bandwidth shaping options are available to Tor relays?
  ...
  Linux-based Tor nodes have another option at their disposal: 
  they can prioritize Tor traffic below other traffic on their 
  machine, so that their own personal traffic is not impacted 
  by Tor load. A script to do this can be found in the Tor 
  source distribution's contrib directory."

Perhaps this should be caveatted?

-Martin