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

[George Kadianakis]

Reinaldo de Souza Jr <rjunior at thoughtworks.com> writes:

> That would be great!
>

OK. Let's say Wednesday 15:00 UTC then!

> 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?
>

Indeed, in the current tor implementation it's a discrete event.

See entry_guards_compute_status() called by directory_info_has_arrived().

> 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?
>

Took a quick look and I think you are right.

node_get_by_id() uses the global nodelist for lookups. The global nodelist gets
updated everytime tor receives a new consensus. So if node_get_by_id() can't
find a node, it means it was not listed in the previous consensus.

Specifically in entry_guards_compute_status() we have:

  SMARTLIST_FOREACH_BEGIN(entry_guards, entry_guard_t *, entry)
    {
      const node_t *r = node_get_by_id(entry->identity);
      const char *reason = NULL;
      if (entry_guard_set_status(entry, r, now, options, &reason))
        changed = 1;
        ...
    }
  SMARTLIST_FOREACH_END(entry);

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

I think tor uses entry_guard_t simply as a store of guard-related information
about a node. However, to actually do networking with a node (e.g. connect to
it) you need to go from entry_guard_t to node_t, because it's node_t that has
networking capabilities.

Cheers!

> 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!
>>