Nick Mathewson nickm@alum.mit.edu writes:
On Fri, Mar 9, 2012 at 5:01 AM, George Kadianakis desnacked@riseup.net wrote: [...]
I like. That was what I wanted to do originally, but I then discarded it as non-future-proof enough.
Let's pump it up to "The body of the 'RATE_LIMIT' command should carry two integers describing 'bytes per second'. Each of them is 8 bytes, big-endian...".
That comes to 18.45 exabytes per second, which should be quite future-proof.
If we're trying that hard to be future-proof, let's have separate read and write caps, in case we need them someday.
I see what you mean :) OK, the updated proposal is doing it with _4_ bytes, big-endian.
The Tor developers of the future, can make a 'RATE_LIMIT_2' command.
<snip>
I also agree that there should be a way for the transport to report to Tor how many bytes it's actually using.
Specifically, my proposal does *not* specify how transport proxies pass usage statistics to tor. This is quite needed at the moment.
We could have a similar BYTES_USED command sent from the proxy to Tor. Probably we should reserve a range of command values for use by commands like this where the transport proxy is reporting stuff to Tor that isn't in response to a command from Tor.
I decided to not include any statistics information in this version of the proposal. Let's do that as part of #5040 ASAP.
Inlining the updated proposal in my next mail.