Opened 3 years ago

Closed 15 months ago

#17625 closed enhancement (fixed)

Reduce initial and ongoing RendPostPeriod for SOS

Reported by: teor Owned by: teor
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: sos, rsos, single-onion tor-hs
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Initial descriptor uploads

Hidden services hide their start times by uploading their first descriptor after:
now + rendinitialpostdelay + crypto_rand_int(2*rendpostperiod);
which is currently 30 + rand(2*600) seconds minimum.

A RSOS doesn't need to hide its startup time, but should avoid a thundering herd. So we could change it to:
now + rendinitialpostdelay + crypto_rand_int(1*rendpostperiod);
(Or perhaps some fraction of RendPostPeriod, or perhaps a constant like 60 seconds.)

Ongoing descriptor uploads

If a RSOS site implements failover or high availability, it may need to post descriptors more often than the current minimum RendPostPeriod of 10 minutes.

For example, if a RSOS goes down, and another instance should replace it within 30 seconds, it would need:
600/30 = 20 redundant instances

Instead, if we want a small number of instances, say 4:
30 * 4 = 120 second RendPostPeriod.
(This also helps with the initial post period above.)

This is perhaps mitigated by multiple HSDirs, with some having descriptors from one replica, and some from the other. (But this is not guaranteed - one replica could have just uploaded all the HSDirs, then gone down.)

This also needs a proposal update.

Child Tickets

Change History (13)

comment:1 Changed 3 years ago by teor

Priority: MediumLow

If Alec says this is working fine in the wild, maybe we don't need to reduce the RendPostPeriod.
(I'll leave it in the proposal, but if it's not necessary, we won't implement it.)

comment:2 Changed 3 years ago by teor

Keywords: rsos sos added

comment:3 Changed 3 years ago by teor

We should at least avoid the random delay before posting for (R)SOS - it's not needed.
Otherwise, let's keep the post delay limits and defaults as-is, and individual operators can set them lower if it fits their use case.

comment:4 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

It is impossible that we will fix all 226 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "new" and tickets, looking for things to move to 0.2.9.

comment:5 Changed 3 years ago by teor

Keywords: TorCoreTeam201602 added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.8.x-final
Owner: set to teor
Status: newassigned

I think I can get this fixed as part of #17178.

comment:6 Changed 3 years ago by teor

Keywords: rsos TorCoreTeam201602 removed
Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Parent ID: #17178#18178
Summary: Reduce initial and ongoing RendPostPeriod for RSOSReduce initial and ongoing RendPostPeriod for SOS

Resolved in #17178 by only adding a random delay to the initial rendpostperiod for hidden services, and not for RSOS.

Still needs to be done for SOS, reparenting to #18178 so I remember to do it.

comment:7 Changed 2 years ago by isabela

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

tickets market to be removed from milestone 029

comment:8 Changed 22 months ago by teor

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

Milestone renamed

comment:9 Changed 21 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:10 Changed 16 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 15 months ago by teor

Keywords: rsos single-onion added
Parent ID: #18178

comment:12 Changed 15 months ago by nickm

Keywords: tor-hs added

comment:13 Changed 15 months ago by teor

Resolution: fixed
Status: assignedclosed

We aren't going to implement the ORPort form of single onion services, so this ticket is done.

Note: See TracTickets for help on using tickets.