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... (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)?