Re: [tor-dev] Proposal Waterfilling

Hi,

On 4 Mar 2018, at 02:37, Florentin Rochet <florentin.rochet@xxxxxxxxxxxx> wrote:

I have a few questions about convergence/divergence of weights, but
maybe we could take advantage of the meeting in Rome to discuss this avenue?

I was wrong. The current network doesn't attempt to converge

on a stable set of weights, because the feedback loop is too

weak. So I think we can disregard this question.

On 28/01/18 23:40, teor wrote:
<skip>
I'm going to re-ask this questions, in light of the extra middle load from
Tor2web clients:

Does the waterfilling proposal make excessive load on middles worse, by
allocating more middle weight to higher capacity relays?

If bwauths overestimate top relays, or if we reach some soft limit, yes.
But the reverse would be true too: if we have excessive load of guards,
then this proposal will make things better.

I'm not sure that this statement is true.

Rather:

If we have excessive load on middles, then top relays will suffer more.

If we have excessive load on guards, then lower relays will suffer more.

You can actually lose both ways when you unbalance network load.

It depends on the type of load.

In particular, connections are limited by file descriptors, and file
descriptor
limits typically don't scale with the bandwidth of the relay. As far
as I can tell,
waterfilling would have directed additional Tor2web traffic to large
guards.
It would have brought down my guards faster, and made it much harder
for me
to keep them up.

If we had implemented waterfilling before this attack, would it have
lead to
cascading failures on our top guards? They would have been carrying
significantly more middle load, and mine barely managed to cope.

Probably yes, but they would also carrying less load at the guard
position from normal Tor users. In normal condition, that should tie. In
a DDoS situation, I would say we face difficulties no matter what we do.

I think that unbalanced networks tend to suffer more during a DDoS.

…
<skip>
Bandwidth-weights and measurements (consensus weights) are two different
things that solve 2 different problems. So, we can work independently on
improving measurements (like what is currently done with bwscanner) and
improving Tor's balancing (bandwidth-weights) with this proposal.

I don't think this is realistic.
There is always contention for shared resources.

Integrating and testing new code, and monitoring its effects, will
take effort from
the teams I mentioned above. This takes away from the urgent work of
fixing the
bandwidth authority system. Which also takes effort from the Core Tor and
Metrics teams.

Right, totally agree that the first focus should be on bwauths. Could we
try to make plan, or at least move this proposal into the todo list?

While we're talking priorities, I would also prioritise fixing the

guardfraction code over this proposal. When we work out how to test

guardfraction, we can use similar tests for this proposal.

At the moment, this proposal is "OPEN", because it is still under

discussion:

https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt#n148

If you want to move it to "ACCEPTED":

* answer as many open questions as you can

* reply to this thread with a link to the final version of the proposal

* we will open a ticket for the proposal

* we will schedule a proposal meeting on IRC to discuss the proposal

Please be aware:

* It sometimes takes years for research to make it into Tor.

* Some research is good research, but it is not a good fit for the public

Tor network.