[tor-dev] Reducing initial onion descriptor upload delay (down to 0s?)

[teor]

> On 8 Sep 2016, at 01:40, Ivan Markin <twim at riseup.net> wrote:
> 
> Hi tor-dev@!
> 
> Moving the discussion on the future of rendinitialpostdelay from ticket
> #20082 [1] here.
> 
> Transcribing the issue:
>> At the moment descriptor is getting posted at
>> MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service
>> initialization. For the use case of real-time one-time services
>> (like OnionShare, etc) one has to wait for 30 seconds until this
>> onion service can be reached. Besides, if a client tries to reach
>> the service before its descriptor is ever published, tor client gets
>> stuck preventing user from reaching this service after descriptor is
>> published. Like this: Could not pick one of the responsible hidden
>> service directories to fetch descriptors, because we already tried
>> them all unsuccessfully.
> 
> 
>> It has jumped to 30s from 5s due to "load on authorities".
>> 11d89141ac0ae0ff371e8da79abe218474e7365c:
>> 
>> +  o Minor bugfixes (hidden services): +    - Upload hidden service
>> descriptors slightly less often, to reduce +      load on
>> authorities.
>> 
>> "Load on authorities" is not the point anymore because we don't use
>> V0 since 0.2.2.1-alpha. Thus I think it's safe to drop it back to at
>> least 5s (3s?) for all services. Or even remove it at all?
> 
> The questions are:
>  * Can we drop this delay? Why?

It doesn't actually gain us anything - we originally added it to prevent load on the authorities, and then we put HS descriptors on HSDirs instead. However, I have concerns that too fast a rate could DoS HSDirs in some circumstances. Even with intro point rebuild limits.

>  * Can we set it back to 5s thus avoiding issues that can arise after
> removing the delay?

Let's base the delay on the amount of time it takes for a HS descriptor to stabilise.
This is the situation we're trying to prevent:
* the HS opens all its intro point circuits
* it sends its descriptor
* one of the intro points fails
* it sends another descriptor

If this hardly ever happens in the first 30 seconds, we likely don't need any delay at all.
But how could we measure how frequent this is, and how long it takes?

>  * Should we do something now or postpone it to prop224?

It would be nice to have this change in 0.2.9 for Single Onion Services and I think also for HSs with OnionBalance

> 
> [1] https://trac.torproject.org/projects/tor/ticket/20082
> --
> Ivan Markin
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160908/f3bfff2a/attachment.sig>