On Fri, Mar 9, 2012 at 5:01 AM, George Kadianakis desnacked@riseup.net wrote: [...]
Hm, when I thought of 'WANT_CONTROL', I was considering that there might be transports that absolutely _require_ the use of TransportControlPort. Since we don't have such transports at the moment, and the short-term future transports don't seem to require TransportControlPort, I guess it could be OK to diss WANT_CONTROL for now.
Still, I'm not sure if tor should do business with a transport proxy that does _not_ support the TransportControlPort protocol. It wouldn't surprise me if there are bridge operators out there who consider rate-limiting essential.
I think we'll do better to just support stuff that doesn't support this protocol. Yes, it's important for quality-of-implementation, but from a development POV, it is a pain to require that every plugin developer support this protocol too -- and that you support this protocol before you can even test your plugin with Tor.
[...] Snipping stuff where we don't disagree about what to do with the proposal.
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.
When the transport proxy sets the appropriate rate limiting, it should send back a 'RATE_LIMITED' command. If it fails while setting up rate limiting, it should send back a 'NOT_RATE_LIMITED' command.
After sending a 'RATE_LIMIT' command. the tor bridge might want to stop pushing data to the transport proxy, till it receives a 'RATE_LIMITED' command. If, instead, it receives a 'NOT_RATE_LIMITED' command it might want to shutdown its connections to the transport proxy.
# is this realistic?
Hm. There probably also wants to be an overall rate limit that applies to all connections. Also, there should be a way for the transport to report to Tor how many bytes it's actually using, I think, if the bytes on the wire are more vebose than the traffic they encode.
Actually, when I was thinking of 'RATE_LIMIT', I was thinking that the rate limit value describes "the overall rate limit that applies to all connections". I _wasn't_ thinking of it as per-connection. I know it feels stupid and/or unintuitive to specify the global rate limit in a per-connection stream, but it seemed like the simplest way to do it. What do you think?
I think we could probably get away with a global rate limit here.
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.
looking forward to the next version,