Traffic class QoS patch wanted?

Mike Perry mikepery at fscked.org
Sun Feb 13 22:42:44 UTC 2005


Thus spake Nick Mathewson (nickm at freehaven.net):

> On Sat, Feb 12, 2005 at 05:36:40PM -0600, Mike Perry wrote:
> > So I'm considering trying to hack conn->outbuf to be a priority queue
> > based on the idea I presented in
> > http://archives.seul.org/or/talk/Feb-2005/msg00042.html. I'm thinking
> > that the best place to implement this is by modifying
> > connection_write_to_buf and connection_handle_write to use a priority
> > queue (or maybe four or five buckets) for conn->outbuf instead of
> > doing the memcpy and sending the whole thing at once.
> > 
> > Relay cells could be dispatched by the priority encoded in the length
> > field, and all other traffic can be given a priority as high as or
> > higher than interactive relay traffic.
> 
> This sounds like a good idea, and I'd like to see how it would work in
> practice.  Here are some possible issues with your actual proposal:
> 
>     - You'd want to put the information into the priority queues
>       _before_ you encrypted it, since you can't re-order the relay cells
>       in a circuit once they're encrypted.

Yeah, so long as I get this done before the tor_tls_write in
connection_handle_write, this should be ok, assuming the below issues
are addressed, right? I'm thinking of doing the sorting into buckets
in connection_write_to_buf, and the reordering just before the
flush_buf_tls call in connection_handle_write.

>     - Using the high bits of the length field will probably not work;
>       remember, they are encrypted and decrypted along with the rest
>       of the body of the relay cell, so the intermediate servers won't
>       see them.  Maybe it would make more sense to have specific
>       circuits have QoS set, rather than doing it at the cell level.

Doh, looks like I didn't read the spec close enough. I assumed that
only the payload was re-encrypted in tor_tls_write. Woops.

So if my current interpretation is correct, only the circid and the
command will be sent in the clear, correct?

How about borrowing the two bits from the command field of the cell
header? It would basically be like creating 4 types of relay commands
depending on priority.

>     - There are probably anonymity issues here that need to get
>       thought about.

I think that doing this per-circuit would be bad because it would seem
that you are then going to tend towards one connection/circuit.. I may
be wrong though.. 

If there are only 4 traffic classes, it might make association easier
by like a factor of 4, but is there much more danger than that?

> Sure, we accept patches, and do so often.  One issue is that we get
> way more design ideas than we get patches, so we don't always assume
> that people are going to work on their designs.  If you want to get a
> significant design feature into the main tor distribution, it's
> usually a good idea to submit a patch to tor-spec.txt first, so we can
> talk about the actual details of the design before you spend too much
> time on the implementation.

Ok. I'll see about doing this next.




-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs



More information about the tor-dev mailing list