Opened 3 years ago

Closed 3 years ago

#23110 closed defect (fixed)

prop224: Rate limit HS descriptor reuploads

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop224 prop224-extra tor-hs
Cc: Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor: SponsorR-can


prop224 services currently re-upload their HS descriptor everytime they receive new dir info (descriptors) if they are close to 100% visibility of the network.

This is done to make sure we always publish to the right HSDir nodes, but it could also lead to uploading lots of descriptors in a small time frame.

A good fix for this would be to cache the previous set of responsible HSDirs (maybe on the desc), and avoid reuploading the same descriptor if the set of HSDirs is the same even if we received new dirinfo.

Also we should probably add a cache to avoid publishing the same descriptor multiple times in a small timeframe anyway.

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by arma

See also the discussion in #23126 around why it would be useful to be able to predict how many publishes an onion service will do over time on average.

comment:2 Changed 3 years ago by asn

#23170 is also relevant. It's about including the ed keys in the consensus which means that we won't have to do all these weird reuploads.

comment:3 Changed 3 years ago by asn

FWIW, an initial attempt for this feature was made as part of the #17242 branch.

comment:4 Changed 3 years ago by asn

Resolution: fixed
Status: newclosed

The solution suggested in the top post has been merged as part of #17242.

Let's reopen this ticket if it ends up not being good enough.

Note: See TracTickets for help on using tickets.