Periodically republish the descriptor

The descriptor publisher needs to implement this part of the spec:

Specifically, every time a hidden service publishes its descriptor, it also sets up a timer for a random time
between 60 minutes and 120 minutes in the future. When the timer triggers, the hidden service needs to 
publish its descriptor again to the responsible HSDirs for that time period. [TODO: Control republish period 
using a consensus parameter?]

changed milestone to %Arti: Onion service support

added Backlog Onion Services Onion Services: MUST Q1 labels

assigned to @gabi-250

changed the description

I think that it is okay to not implement this part, so long as we publish every time the descriptor changes, the descriptor expires, or the set of hsdirs change.

@dgoulet do you remember why we do this?

mentioned in issue #1242 (closed)

Quick question: is this currently implemented in C Tor?

do you remember why we do this?

I don't know exactly why this is specified in first place (maybe descriptors expire in HSDirs after a while?), but leaving this not implemented may impact the way some load balancing setups actually works.

The simpler "load balancing approach" (or at least failover) consists in just running multiple daemon instances in parallel with the same set of Onion Services (which is different than using Onionbalance).

In theory, each daemon would have it's own random time to re-upload descriptors, which can be further randomized by starting each tor daemon in different times. It's expected that clients would randomly pick descriptors for one or another daemons.

If there's no periodic re-publishing at random times, I imagine that descriptors would be published only for SRV changes and service restarts, thus losing this simple failover capability.

IMO: If this is the only reason for re-publishing information that we already uploaded, we can probably call this non- Onion Services: MUST, and possibly add a feature to decide whether to do this.

@dgoulet @mikeperry Any thoughts on this issue?

Quick question: is this currently implemented in C Tor?

Yes it is.

Reason is that as you said HSDir will expire descriptors I think after 3 hours iirc and so the service keeps updating it at a random time every 60-120min to be ahead of that. Also to account for relay restart.

Now keep in mind that there are several reasons why service would re-upload a descriptor before that 60-120 minute timeframe.

1. PoW seed/effort change/expiration every 105min to 120 min will trigger a republish.
2. Introduction circuit collapsing (unknown when)
3. Introduction point rotation (based on number of introduction or time that is random time between 18 to 24h)
4. Hashring changes. Basically, if the directory information changes and we noticed the hashring changes, we republish. (with every new consensus).
5. SRV changes (consensus)

Thanks!

As I understand, PoW may trigger a republish every 5 minutes if effort have changed noticeably.

And for the record, I have documented this behavior in this Onionspray guide (our recent EOTK fork).

Reason is that as you said HSDir will expire descriptors I think after 3 hours iirc and so the service keeps updating it at a random time every 60-120min to be ahead of that. Also to account for relay restart.

Ah, good point, I hadn't thought about the relay restart case.

4. Hashring changes. Basically, if the directory information changes and we noticed the hashring changes, we republish. (with every new consensus).

This is somewhat orthogonal to the original question, but the hashring doesn't (usually) change unless we enter a new time period, correct? I realize it is possible for it to change even if the time period stays the same, because when the consensus changes, the hsdir_n_replicas, hsdir_spread_fetch, hsdir_spread_store params could be different, but these don't change often (or at all), do they?

mentioned in issue #1210 (closed)

removed Backlog label

added Doing label

mentioned in merge request !1936 (closed)

removed Doing label

added Needs Review label

removed Needs Review label

added Doing label

mentioned in merge request !1951 (merged)

removed Doing label

added Doing label

mentioned in merge request !1971 (merged)

removed Doing label

added Needs Review label

mentioned in commit c04d6010

closed with commit e1f8793f

closed with merge request !1971 (merged)