[tor-dev] Proposal Waterfilling

[teor]

Hi,

> On 4 Mar 2018, at 02:37, Florentin Rochet <florentin.rochet at uclouvain.be> 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.

T

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180304/3588d922/attachment.html>