[tor-dev] Pre-draft of Proposal XXX: Extended ORPort and TransportControlPort

[Nick Mathewson]

On Fri, Mar 9, 2012 at 5:01 AM, George Kadianakis <desnacked at 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,
-- 
Nick