flow control questions

[Mike Perry]

Thus spake Christian Seberino (chris at seberino.org):

> So basically ORs have a a limit on number of Relay Data cells they are
> willing to send down/up the circuit in **each direction**?
>
> It appears, when an OR can send more cells, it sends a RELAY_SENDME to OP
> which may respond with another RELAY_SENDME back to OR right?  Do BOTH of
> these RELAY_SENDMEs cause (both?) the OR's windows to increase (by 100)?
> 
> So ORs have freedom to send out tons of RELAY_SENDMEs to increase its
> windows?  So OPs have freedom to send out tons of RELAY_SENDMEs to
> increase OR  windows?  Then why aren't windows vulnerable to attack since
> both ORs and OPs can just pump out more RELAY_SENDMEs to increase windows
> whenever they want?  What prevents manipulation?

Roger unfortunately is sick, and according to SVN he apparently owns
most of this flow control stuff. I'm interested in hearing an
"official" opinion on this as well.

It would seem to me that exploiting this won't really get you better
service (or at least it shouldn't. There is a suspicious TOR_PERF
ifdef in the source however). Tor's flow control really isn't designed
to provide any sort of rate limiting or fairness, it's really designed
to avoid running out of memory while buffering cells over multiplexed
channels. If you remove flow control (which is effectively what you
are doing by lying), at some point the TCP connections involved will
block, eventually causing an upstream Tor node to buffer cells
forever, OOM and die, or at least choke out other circuits when the
TCP block does happen.

So its more so of a DoS than anything, though there may be code
burried somewhere that has auxillary flow control for when TCP blocks.
What really should exist is some code that caps the packaging window
PLUS all buffered cells at 1000 and gives a TORPROCTOL error if this
limit is exceeded. I can't find this code though.


When you get this component working I'd be very interested in having a
look at your code. I'm interested in trying to determine how well this
system performs on various types of links, and when multiple hops of
varying latencies and BDPs are involved. I probably should add some
controller events for the blocked condition as well for my node
monitor, since I vaguely suspect this component may be responsible for
circuits suddenly choking for no reason (which happens from time to
time).

In general you should put your code up somewhere (especially stuff
that has working unit tests or other mechanisms for self-testing).
Maybe if you ask nicely Nick or Roger will give you an svn module to
commit to.  That would be ideal.

Again, I for one am very glad you're doing this. Having an easily
modifiable implementation will hopefully accelerate research and
experimentation on the protocol. C is kind of.. cumbersome for this
purpose (heheh, for any purpose! ;)


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