Opened 2 months ago

Last modified 10 days ago

#26769 merge_ready defect

We should make HSv3 desc upload less frequent

Reported by: asn Owned by: neel
Priority: Medium Milestone: Tor: 0.3.6.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs network-health easy hsdir
Cc: neel@… Actual Points:
Parent ID: Points:
Reviewer: asn Sponsor:

Description

Without checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see HS_SERVICE_NEXT_UPLOAD_TIME_MIN).

This makes HSv3s upload descriptors more frequently than needed. For example, we could increase this to upload descriptors between 2 and 2.9 hours, to make HSv3s less intense on the network.

Someone should double check the above logic and make sure it won't cause issues, and implement it.

Child Tickets

Change History (9)

comment:1 in reply to:  description Changed 2 months ago by arma

Replying to asn:

This makes HSv3s upload descriptors more frequently than needed. For example, we could increase this to upload descriptors between 2 and 2.9 hours, to make HSv3s less intense on the network.

The main reason v2 onion services uploaded so frequently (way more frequently than this) is to handle relays that restart (and thus discard all of their onion service descriptors) and relays that rotate into a spot in the hash ring that makes them now responsible for this onion address.

I wonder how much churn there is in practice, as a function of our HSDir assignment algorithm.

comment:2 Changed 3 weeks ago by neel

Cc: neel@… added
Owner: set to neel
Status: newassigned

comment:4 Changed 3 weeks ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.5.x-final
Status: assignedneeds_review

comment:5 in reply to:  description ; Changed 3 weeks ago by arma

Replying to asn:

HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours)

Are there clock skew issues to worry about here? Like, an onion service whose clock is off by an hour, thus causing the hsdir to cache it for less time than we would otherwise expect?

comment:6 Changed 3 weeks ago by asn

Reviewer: asn

comment:7 in reply to:  5 Changed 3 weeks ago by asn

Replying to arma:

Replying to asn:

HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours)

Are there clock skew issues to worry about here? Like, an onion service whose clock is off by an hour, thus causing the hsdir to cache it for less time than we would otherwise expect?

I don't think that's an issue because the lifetime field is the number of seconds after which the descriptor should expire; and not an absolute date string. So the lifetime says "3 hours" and HSDirs will hold it for 3 hours before expiring it, regardless of clock times.

comment:8 in reply to:  3 Changed 3 weeks ago by asn

Milestone: Tor: 0.3.5.x-finalTor: 0.3.6.x-final
Status: needs_reviewmerge_ready

Replying to neel:

PR is here: https://github.com/torproject/tor/pull/303

Thanks for the patch. LGTM.

However, given that descriptor upload is still a bit unstable in v3 (#25552 / #26980 / #27436) I'm considering whether we could perhaps keep the frequent upload schedule since it can save us from reliability issues if a single descriptor upload fails (like it happens in #26980 and #27436).

Perhaps we can merge this in 036? Or later in 035, after we make sure we have killed all known descriptor upload issues?

comment:9 Changed 10 days ago by dgoulet

Agree with asn. Going to the 180 minutes line might be dicy considering some unresolved issues we have right now with descriptor being rejected by the HSDir.

Note: See TracTickets for help on using tickets.