[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #13207 [Tor]: Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?

#13207: Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?
------------------------+------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.???
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  SponsorR, tor-hs
Actual Points:          |  Parent ID:
       Points:          |
------------------------+------------------------------

Comment (by special):

 Yes.

 First of all, this value is used by clients *and* hsdirs. Unless I've
 missed something, this means that a client which accesses a HS, waits two
 days without restarting, then tries again will reach out to all old intro
 points before fetching a new descriptor.

 I think it's worth looking at this as two separate cases:

 There is no value in serving descriptors older than the descriptor-id time
 period of 24 hours. A client with a clock this inaccurate can't be
 expected to function. These descriptors are unlikely to be queried and
 even less likely to be useful. The best implementation is to clean these
 when the descriptor-id for that service changes, with some fuzz for clock
 skew.

 The current value is too high, considering that RendPostPeriod is usually
 one hour; a 4-hour-old descriptor on a HSDir is almost certainly useless.
 But, I don't see a very compelling reason to reduce it below 24 hours
 either. The value used here is effectively a maximum value for
 RendPostPeriod.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13207#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs