Hello,
On 28/01/18 11:52, teor wrote:
Hi,
I have some more questions:
Nice, thanks! I still have to answer your previous email and push an update to the proposal. I should do it this week, sorry for late answers :)
See inline a few answers to your questions:
On 18 Jan 2018, at 11:03, teor teor2345@gmail.com wrote:
Unanswered questions:
The Tor network has been experiencing excessive load on guards and middles since December 2017.
If I have correctly followed what was happening: around 1M tor2web clients appeared at OVH and started to overload the network with circuit creation requests using the old and costly TAP handshake. Tor2web clients make direct connections to the intro point and to the rendezvous point, right? And, looking into the code right now, it does not looks like Tor2webs make any distinction to flags. So, basically, the Tor2web load is only weighted by consensus weight (bandwidth-weights have no impact) on the overall network (exits too). Guess: shouldn't that the reason why all exits logs are flooded with the message "[warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)"? Those messages would be caused by tor2web clients picking exit relays as rendezvous node :/ I started to see them increasing more and more since August 2017.
So basically, I *think* we can drop the questions below because bandwidth-weights do not play any role in the excessive load that the network is handling with those tor2webs.
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?
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 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? Could you be more specific about your concerns with the bandwidth authorities and this proposal?
Who will maintain the new code we add to Tor to implement waterfilling?
I would volunteer to that.
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.
Do the benefits of waterfilling justify this extra effort?
Question for the other Tor devs :) I am definitely biased towards the "yes"
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.
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:
- Consensus weights on guards and middles change
- Client use of guards and middles change
- Bandwidth authority measurements of guards and middles change
- 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.
Best, Florentin
T _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev