[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Proposal Waterfilling

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@xxxxxxxxx> 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:
>>>> 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.

Best,
Florentin

>
> T
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev