[tor-dev] Pluggable Transports and rate limiting

[George Kadianakis]

Andreas Krey <a.krey at gmx.de> writes:

> On Tue, 10 Sep 2013 14:17:12 +0000, George Kadianakis wrote:
>> Hey Yawning (and tor-dev),
>> 
>> a topic that we will soon need to consider seriously is rate limiting
>> of pluggable transports. For example, Obfsproxy at the moment does not
>> understand rate limiting and will happily read and write as many bytes
>> as needed.
>
> My first reaction: Why should it care? As long as it only reads from
> the input as long as the output isn't/wouldn't be blocking, all
> is fine with the transport - it behaves like the direct TCP bridge
> protocol.
>

The problem here is that 'len(<data Tor->PT>) != len(<data PT->Internet>)'.
For example, a PT might be implementing an HTTP transport which has an
overhead over the simple Tor TLS connection. So Tor cannot track the
actual number of bytes sent to the network.

> ...
>> For example, I'm kind of sad about this approach, because it requires
>> little-t-tor to do all the hard work of monitoring bandwidth usage and
>> giving out intelligent rate-limiting orders.
>
> So, why not? I think it is easier to implement that in one place than
> needing to reimplement it in any pluggable transport again (or at least
> once per implementation language).
>
> After all, tor is the one who sees the total traffic anyway, and thus
> is in a unique position to throttle in a fair way, for any definition
> of 'fair'.
>
> And it also means that we can throttle the regular bridge protocol
> as well. Which actually makes me wonder: Why do you expect that we
> need this kind of rate-limiting?
>

We need this kind of rate limiting to allow people to say "I want to
donate 80kb/s to Tor; the rest of the bandwidth is mine.".

BTW, posting here two more PT-rate-limiting ideas (instead of the
currently proposed RATE_LIMIT command) proposed by Andreas and Lunar
in IRC:

* PTs calculate their overhead and send a "fudge factor" to Tor when
  they start up (for example, if an HTTP transport has 30% overhead
  over the underlying TLS connection, the fudge factor is 30%), which
  Tor uses to calculate the actual number of bytes sent to the network
  and do rate-limiting/accounting on its own.

  Unfortunately, I doubt that PTs have a constant fudge factor.

* PTs periodically send to Tor (over the TransportControlPort or
  something) how many bytes (or how many bytes overhead) they have
  pushed to the network. These numbers are used by Tor to update its
  traffic stats and enforce rate-limiting/accounting on its own.