Opened 6 years ago

Last modified 17 months ago

#6761 new defect

PDS_NO_EXISTING_SERVERDESC_FETCH is somewhat archaic

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay download bootstrap refactor sponsor8-maybe
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In bug #366 we made it so Tor won't open a second dir fetch to an authority if it has one already. Great.

        rs = router_pick_trusteddirserver(type, pds_flags);
        if (rs == NULL && (pds_flags & (PDS_NO_EXISTING_SERVERDESC_FETCH|
                                        PDS_NO_EXISTING_MICRODESC_FETCH))) {
[...]
            log_debug(LD_DIR, "Deferring serverdesc fetch: all authorities "
                      "are in use.");

But we didn't update it to look for begindir conns, so it only applies to direct dir fetches. Ok.

      if (no_microdesc_fetching) {
        if (connection_get_by_type_addr_port_purpose(
             CONN_TYPE_DIR, &addr, d->dir_port, DIR_PURPOSE_FETCH_MICRODESC)) {
          ++n_busy;
          continue;

So it doesn't apply to clients, only relays. That makes sense, because relays are the ones who typically would contact authorities anyway.

  int prefer_authority = directory_fetches_from_authorities(options);

But when a relay starts up and gets a consensus, it has a line like this nowadays:

Sep 04 05:47:40.000 [info] launch_descriptor_downloads(): Launching 33 requests for 3114 routers, 96 at a time

33 requests! Surely that's way more than the 8 or so authorities we have. And relays don't use begindir to talk to authorities, since it slows them down too much:

  int use_begindir = supports_begindir &&
                     directory_command_should_use_begindir(options, _addr,
                       or_port, router_purpose, anonymized_connection);

Doesn't that mean we hit the "one per authority" limit and drop the rest of those requests?

It turns out that directory_fetches_from_authorities() is false for most relays when they start up:

  if (server_mode(options) && router_pick_published_address(options, &addr)<0)
    return 1; /* we don't know our IP address; ask an authority. */
  refuseunknown = ! router_my_exit_policy_is_reject_star() &&
    should_refuse_unknown_exits(options);
  if (options->DirPort == NULL && !refuseunknown)
    return 0;
  if (!server_mode(options) || !advertised_server_mode())
    return 0;
  me = router_get_my_routerinfo();
  if (!me || (!me->dir_port && !refuseunknown))
    return 0; /* if dirport not advertised, return 0 too */
  return 1;

So these relays end up asking arbitrary other relays they found in the consensus! Cue Nick's circus music here. Not the best way to get fresh info.

In my case here (and I expect it's a common case), my relay failed the "!advertised_server_mode" check, since it hadn't done its reachability test yet so it hadn't published a descriptor yet.

Maybe this is actually a feature that just-starting-up relays don't fetch descriptors from authorities. It probably doesn't hurt much, and probably helps authority load a bit.

But I don't think it's a feature that we allow multiple descriptor-fetching dir requests in parallel to an authority iff they're begindir requests.

Child Tickets

Change History (15)

comment:1 Changed 6 years ago by nickm

oy. Surely we can do better than this.

What do you think *would* be a reasonable behavior here, arma? We surely don't want to have lots of parallel connections to the same directory authority/cache. On the other hand, having the relays ask arbitrary other relays seems wrong too.

My first thought is that maybe before launching descriptor requests, you should determine how many possible directory authority/caches you know that could answer them, and divide your requests among that many authorities/caches?

comment:2 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:3 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:4 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:5 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:6 Changed 4 years ago by andrea

Keywords: 026-triaged-1 026-deferrable added

comment:7 Changed 4 years ago by nickm

The patch for #9969 is a good starting point for any fixes here.

comment:8 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

Defer some items from 0.2.6. They are mostly worth doing, but not going to happen super-fast.

comment:9 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:10 Changed 22 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:11 Changed 17 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 17 months ago by nickm

Keywords: 026-triaged-1 removed

comment:13 Changed 17 months ago by nickm

Keywords: 026-deferrable removed

comment:14 Changed 17 months ago by nickm

Keywords: download bootstrap refactor sposnor8-maybe added
Severity: Normal

comment:15 Changed 17 months ago by arma

Keywords: sponsor8-maybe added; sposnor8-maybe removed
Note: See TracTickets for help on using tickets.