[tor-dev] Meeting about the new guard algorithm proposal (prop259)

[Reinaldo de Souza Jr]

That would be great!

I have a couple of questions that may help me better prepare for this
meeting:


1) In the proposal we assume the arrival of a new consensus as a
discrete event. Does this assumption match current tor implementation,
or is it more like "having at least X relay descriptors available"? What
is the entrypoint for taking actions after we receive a new consensus?

Keep in mind we refer to "receiving a new consensus" meaning "the list
of guards has changed", they might be different things. We are
interested in reacting to changes to the "list of guards".

2) Once we have a guard_t, how can we know if it "is present in the
latest consensus"?

We found the property `bad_since` but it seems to have a different
semantics: when the guard was considered "nonfunctional, unlisted,
excluded, or otherwise nonusable" (according to
`ENTRY_GUARD_REMOVE_AFTER` description).

We also found `entry_guard_set_status` and how it consider a guard to be
unlisted: a failure to find a node with the same identity as the guard
using node_get_by_id().

At this point, my understanding is whatever is "in the consensus" can be
found by node_get_by_id() and `bad_since` can be used as an additional
data for decision making. Is this correct?

3) Current tor implementation seems to prefer handling lists of node_t
rather than entry_guard_t, is there a reason for this?

The proposal implementation currently manipulate lists of entry_guard_t
but when we need to call functions in existing tor code
(node_sl_choose_by_bandwidth) we need to convert from guard do node,
using node_get_by_id().

As a consequence, if I'm correct about 2, this will automatically filter
out unlisted guards.

On 3/18/16 04:19, George Kadianakis wrote:
> Hello there,
> 
> seems like the prop259 algorithm has kind of stabilized and you guys have
> jumped into implementation. That's great!
> 
> A small problem in this process is that I'm probably the only person in Tor who
> understands the new algorithm right now. We could fix this by doing a small
> proposal IRC meeting where you guys could summarize the current state of the
> algorithm, as well as provide some simulation results. I think that folks like
> Nick, Mike and isis could provide valuable feedback at this point.
> 
> Would you guys be interested in something like this? I'm fine with doing it
> next week at some point. Maybe Wednesday or Thursday? Maybe at 15:00 UTC?
> Let me know if that's convenient for you.
> 
> Cheers!
> 

-- 
*Reinaldo de Souza Jr* | Software Developer
*Thought*Works Brasil

GPG: E0FD 0487 5CAC 4200 EF25 098A 9FA3 789F 0615 5999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160318/ffb250a2/attachment.sig>