[tor-dev] Pluggable Transports and rate limiting

[George Kadianakis]

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.

After some discussions in IRC and #3587, we decided to add
rate-limiting commands to the TransportControlPort -- that's the
(unimplemented) real-time sister of ExtendedORPort. You can see the
details in the relevant proposal:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/196-transport-control-ports.txt
(see RATE_LIMIT command etc.)

The idea here was that Tor would monitor its bandwidth usage and order
PTs to slow down appropriately. If an accounting limit was hit, Tor
would order PTs to stop pushing traffic completely.

Does this look like a reasonable way to enforce
accounting/rate-limiting policies? How could it be improved?

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. For example, how do we
rate-limit N pluggable transports to 100 kb/s? Do we allow each
pluggable transport to push 100/N kb/s? I don't like that this logic
must be implemented in little-t-tor.

Also, do the TransportControlPort rate-limiting commands look
reasonable? Is the payload of RATE_LIMITED (two integers: bandwidth
rate and bandwidth burst) properly designed, or does it need more
information?

Also also, will this work nicely with transport combos (#7167)?