Guard weights are used by overloading onion services, and middle

weights are used by overloading Tor2web clients.

Does the waterfilling proposal make excessive load on guards worse, by
allocating more guard weight to lower capacity relays?
Is the extra security worth the increased risk of failure?

We want to design a network that can handle different kinds of extra load.

So these questions are important, even if they don't apply right now.

Does the waterfilling proposal make excessive load on middles better, by
allocating more middle weight to higher capacity relays?
Is there a cascading failure mode, where excess middle weight overwhelms
our top relays one by one? (It seems unlikely.)

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?

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.

Can you redesign the proposal so there is some limit on the extra middle load

assigned to a guard? Or does this ruin the security properties?

Is there a compelling argument for security over network robustness?

I also have another practical question:

We struggle to have time to maintain the current bandwidth authority
system.

Is it a good idea to make it more complicated?

Hm, I don't see how Waterfilling plays any role with torflow or
bwscanner? I mean, there is still this feedback loop thing but it has no
impact on the design of the current torflow or bwscanner?

I can't really say.

I look forward to your explanation of the feedback loop.

Could you be
more specific about your concerns with the bandwidth authorities and
this proposal?

It takes time and effort from Tor people to integrate and maintain the

code and monitoring for a new proposal like this one.

We will need to take extra time on this proposal, because we already need

more monitoring for the current bandwidth authority system. And only then

would we have time to build monitoring specific to this proposal.

Also, when we change bandwidth measurement or allocation, we need to

change one thing at a time, and then monitor the change. So depending

on our priorities, this proposal may need to wait until after we implement

and monitor other urgent fixes.

Who will maintain the new code we add to Tor to implement waterfilling?

I would volunteer to that.

Typically, experienced Core Tor team members review and maintain code.

And there's still a lot of development and testing work to be done before

the code is ready to merge. Are you able to do this development?

How much help will you need to write a new consensus method?

How much help will you need to write unit tests?

(This help will come from existing team members.)

Does your current code pass:

* make check

* make test-network-all

* in particular, any new consensus method must pass the "mixed" network,

with an unpatched Tor version in your path as "tor-stable"

Who will build the analysis tools to show that waterfilling benefits the
network?

Volunteers or master students. I can definitely suggest this topic in my
university.

Typically, experienced Tor Metrics team members write, review, and maintain

monitoring systems. And they don't have a lot of extra capacity right now.

Even if students do this task, they would need help from existing team

members.

Do the benefits of waterfilling justify this extra effort?

Question for the other Tor devs :) I am definitely biased towards the "yes"

It seems plausible, but I don't feel I have seen a compelling enough argument

to prioritise it above fixing bandwidth authorities.

At the moment, reasonably fast guards in Eastern North America and Western

Europe are overloaded with client traffic. And guards in the rest of the world

are under-loaded. Reducing this bias is something we need to do.

And this proposal gets us better security if we fix this geographical bias first.

Otherwise, adversaries can simply pick a location that massively increases

their consensus weight, and get lots of client traffic.

And even if they do, should we focus on getting the bandwidth authorities
in a maintainable state, before adding new features?
(I just gave similar advice to another developer who has some great ideas
about improving bandwidth measurement.)

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.

What about the feedback loop between this new allocation system
and the bandwidth authorities?

I am sorry, I don't really understand why a feedback loop is needed. Measuring bandwidth and producing bandwidth-weights seems orthogonal to me.
You do not need to add a feedback loop, one already exists:
1. Consensus weights on guards and middles change
2. Client use of guards and middles change
3. Bandwidth authority measurements of guards and middles change
4. Repeat from 1

My question is:

How does this existing feedback loop affect your proposal?
Does it increase or reduce the size of the guard and middle weight changes?
I have added those questions to the proposal. This looks difficult to know.
Can shadow simulate this?
I am still interested in this feedback loop.
If it fails to converge, the system will break down.

Yup. Going to answer this on your previous email.