Opened 5 months ago

Closed 4 months ago

Last modified 4 months ago

#24425 closed enhancement (fixed)

Set the hsdir_spread_store parameter to 4 (or maybe even 5)

Reported by: nickm Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: review-group-27, 031-backport-maybe
Cc: teor Actual Points:
Parent ID: Points:
Reviewer: teor Sponsor:

Description

Based on analysis at #23170, this should improve hidden service reliability.

I'm voting for "4" instead of "5" because of the analysis there.

Child Tickets

Change History (15)

comment:1 Changed 5 months ago by dgoulet

Just as an extra data point, this means that services will upload descriptors to 8 or 10 HSDirs now. In other words, almost double from v2 in terms of load on the network. I don't think it is that dramatic, this happens every 3 hours or so with v3 or when we rotate intro points.

comment:2 Changed 5 months ago by teor

Cc: teor added

comment:3 Changed 5 months ago by asn

Thanks for the useful analysis. I'm fine with bumping up hsdir_spread_store and it seems like a good move.

As a sidenote, I'd like to know more stuff about how much load we put on the network by doing this change (and any other HSDir-related changes). I wonder what would be the right way to measure how much RAM (or other things) these HS descriptors take up from relays.

comment:4 Changed 5 months ago by teor

If you write down a list of exactly what you want to know, we can probably collect some stats on ~18 HSDirs using PrivCount.
We will also need an estimate of how much 1 client / service would contribute to each statistic in 10 minutes.

We could do this in late December or January, depending on the other collections we're doing, and how long we need to collect for to get a good noise ratio. (We need to collect for longer if the totals are small compared to individual client contributions.)

For example:

Number of service descriptor uploads to HSDirs
Estimate: 6 descriptors per service, uploaded every 30 - 90 minutes (Or is it every 2 hours? I can't remember.)

comment:5 in reply to:  4 Changed 5 months ago by asn

Replying to teor:

If you write down a list of exactly what you want to know, we can probably collect some stats on ~18 HSDirs using PrivCount.

Hey teor,

I might be hijacking this ticket by suggesting the following stats but here are some basic ideas:

  • How many v2/v3/both descs per HSDir?
  • How much total RAM do all v2/v3/both descs occupy on your hsdirs? (max,min,avg,mean over your 18 hsdirs)
  • Size variance of v2/v3 descs? (max,min,avg,mean)
  • What's the rate of incoming v2/v3/both descs?
  • How many failed requests for HS descriptors over time? (percentage over total requests?)

These are just the obvious stats that I came up with. We can come up with more stuff as we see some results and understand the space better.

Let me know if you need help in turning the above sentences into methodologies.

We will also need an estimate of how much 1 client / service would contribute to each statistic in 10 minutes.

Is that to figure out the noise for differential privacy? Let's try to come up with the final stats list and then we can figure this out.

Should we make a separate ticket (child of this one) for this task?

comment:6 in reply to:  3 Changed 5 months ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

Replying to asn:

Thanks for the useful analysis. I'm fine with bumping up hsdir_spread_store and it seems like a good move.

We have two choices, bump it in 032 code or/and via consensus param. Since 032 is not stable yet, I think we can just sweep in and change it in the code then once released we can quickly change it if needed via consensus.

See branch that bumps the value to 4 in the code: ticket24425_032_01

comment:7 Changed 5 months ago by dgoulet

Status: acceptedneeds_review

comment:8 Changed 5 months ago by nickm

Keywords: review-group-27 added

comment:9 Changed 5 months ago by teor

Keywords: 031-backport-maybe added
Reviewer: teor
Status: needs_reviewmerge_ready

This is a trivial constant change. It's easy to merge.

Do we also need to ask dir auths to configure this in the meantime?
Or should we backport to 0.3.1?
(All dir auths are on 0.3.1 now, except for moria1, which is on master.)

comment:10 Changed 5 months ago by nickm

Please let's get the directory authorities to set the parameter, so that the clients with older versions of 0.3.2.x aren't distinguishable.

comment:11 Changed 5 months ago by dgoulet

Well this parameter was introduced in 032... So basically, the only ones affected by this are *services* <= next 032 release.

We bumped the "store" parameter so now hidden service will store their descriptor on 4 * replica HSDir.

I think we don't have to do more here, -alpha services will simply use 3 HSDir while the others will use 4, yes the anonymity set is kind of a split but also how many v3 services on -alpha out there? And I think it is fair to assume that they should go on stable and not stay on -alpha for security?

If we do care about that small subset of v3 service, then we need to ask our dirauth to broadcast the new value.

comment:12 Changed 4 months ago by dgoulet

Component: Core Tor/DirAuthCore Tor/Tor

Ok _wrong_ component... This needs to go in 032. I'm emailing the dirauth list to ask about setting this consensus param.

comment:13 Changed 4 months ago by nickm

I see that hsdir_spread_store=4 is now set in the consensus. Ready to merge the the change to 032 IYO?

comment:14 Changed 4 months ago by nickm

Resolution: fixed
Status: merge_readyclosed

per confirmation from dgoulet, merging to 0.3.2 and forward.

Made the corresponding tor-spec change as 405e77f109d7963c11ad04a077e3cc7b11bc21e9

comment:15 Changed 4 months ago by nickm

added 0a1b1430c87824d5f5922827b6ca770a43e709ac to fix the unit tests

Note: See TracTickets for help on using tickets.