Relay on dynamic IP marked as stable and guard

Hi,

I'm running a Tor relay on a dynamic IP which changes every day. At the moment my node is marked as stable and guard which AFAIK shouldn't happen as it isn't stable. I got the information from https://trunk.torstatus.kgprog.com:444/.

This may be related to bug #969 (moved) which was marked as fixed.

Thanks, Simon

[Automatically added by flyspray2trac: Operating System: All]

Trac:
Username: rudis

changed milestone to %Tor: 0.2.4.x-final

added component::core tor/tor milestone::Tor: 0.2.4.x-final owner::Sebastian priority::medium reporter::rudis resolution::fixed status::closed tor-auth type::defect version::0.2.0.35 labels

Trac:
Keywords: N/A deleted, N/A added
Parent: N/A to N/A
Milestone: N/A to Tor: 0.2.2.x-final

Let's have a look through the networkstatus db to see how often routers with changed IPs are marked as Stable/Guard to see if this is still happening.

Assigning this one to Karsten for investigation, since he seems to be Keeper of Networkstatus Deltas these days. Karsten, please un-assign it if it isn't up your alley.

Trac:
Owner: N/A to karsten
Status: new to assigned
Description: Hi,

I'm running a Tor relay on a dynamic IP which changes every day. At the moment my node is marked as stable and guard which AFAIK shouldn't happen as it isn't stable. I got the information from https://trunk.torstatus.kgprog.com:444/.

This may be related to bug #969 (moved) which was marked as fixed.

Thanks, Simon

[Automatically added by flyspray2trac: Operating System: All]

to

Hi,

I'm running a Tor relay on a dynamic IP which changes every day. At the moment my node is marked as stable and guard which AFAIK shouldn't happen as it isn't stable. I got the information from https://trunk.torstatus.kgprog.com:444/.

This may be related to bug #969 (moved) which was marked as fixed.

Thanks, Simon

[Automatically added by flyspray2trac: Operating System: All]

Attached is a graph on the fraction of relays on dynamic and static IP addresses obtaining the Guard and/or Stable flag. I'm considering a relay to be on a dynamic IP address if it's listed with 4 or more different IP addresses in the past 12 months.

So, only very few relays on dynamic IP addresses obtain the Guard flag, but up to 1/4 of them get the Stable flag. What did we expect these two fractions to be? Something close to zero?

I can look more at the details if someone tells me what to look for. Maybe there's a better way to distinguish static and dynamic IP addresses?

And yes, investigating these things is easy for me. If there are other bugs that need similar analysis, feel free to assign them to me.

Trac:

Fraction of relays on static/dynamic IP addresses obtaining the Guard/Stable flag

Having 4 IP addresses in 12 months isn't a big deal as far as stability is concerned. Having 20 or more -- or having many IPs that were held for less than a week -- would probably pose more of a problem for stability. Are there many Stable nodes like that?

Trac:

Fraction of relays on static/dynamic IP addresses obtaining the Guard/Stable flag where dynamic IP address means 4 or more different IP addresses each assigned for less than 1 week

I changed the criterion for calling an IP address dynamic by requiring 4 or more different IP addresses each assigned for less than 1 week. This reduces the number of relays classified as being on a dynamic IP address from 10273 to 8001 in the same time period. The graph changes a bit, but the number of relays on dynamic IP addresses having the Stable or Guard flag is still not close to zero. Is this expected?

According to Roger, no.

06:27 < armadev> i think you shouldn't get the stable flag if you're never up more than 24 hours 06:28 < armadev> guard would be ok with me

Nick suggests there's a bug where we don't reset wfu/mtbf when the relay's IP address changes. That sounds quite plausible: if it's recently reachable every time we check whether we found it reachable, we'll never mark it not-running, so we'll never register a state change.

Triage: this bug should not block 0.2.2.x-rc. When we finally get around to fixing the wfu/mtbf bugs (which may well involve a proposal and a new design), we can fix them on the authority side, so there's no need to hold up the new stable.

Reassigning to nickm for actual bug fixing. Feel free to reassign to me if there's more archive parsing required.

Trac:
Owner: karsten to nickm

So to clarify, the desired behavior is that when your IP changes, it should be as if you just shut down your router and came back as a new router? That seems suboptimal.

Perhaps instead if your IP changes, we should treat you as having been down since the last time you were observed to be up. This will count as downtime for the purpose of resetting the current MTBF run, and also take a little chunk out of WFU. But maybe it doesn't limit WFU enough. Authorities learn about IP changes more frequently than clients, after all, so an IP change that is only 15 minutes long from the authorities' perspective will be a couple hours from the clients' perspective.

So maybe we should treat an IP change as if it were equal to automatic downtime of the same length as the average propagation time of a server descriptor to a client?

It does appear to me that average propagation time is the right thing here. But what is the average propagation time? This is likely to be two different things when microdescs and normal descriptors are served in parallel, and we don't want to punish the IP-changing relay as much.

Patch in branch bug1035 in my public. Please review?

Trac:
Status: assigned to needs_review