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? * Can we set it back to 5s thus avoiding issues that can arise after removing the delay? * Should we do something now or postpone it to prop224?
[1] https://trac.torproject.org/projects/tor/ticket/20082 -- Ivan Markin
On 8 Sep 2016, at 01:40, Ivan Markin twim@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@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
teor:
- 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?
IMO an onion service should publish its first descriptor instantly. If something happens afterwards and one has to fix the descriptor - deal with it with backoff/delay to prevent DoS on HSDirs. I think that most of the ephemeral services are not going to use more than one descriptor. Moreover, they are going to use just one introduction point. So it's not a big deal if one of the published IPs fails since a client is going to use one of the rest. Also note the reachability issue I mentioned.
It would be nice to have this change in 0.2.9 for Single Onion Services and I think also for HSs with OnionBalance
Same here. Most of the stuff that uses ADD_ONION is meant to setup onion services instantly but has to wait 'until descriptor gets published'. 30s is too much.
-- Ivan Markin
Ivan Markin twim@riseup.net writes:
IMO an onion service should publish its first descriptor instantly. If something happens afterwards and one has to fix the descriptor - deal with it with backoff/delay to prevent DoS on HSDirs.
+1
txtorcon only ever waits for the first descriptor to be published (since at this point I presume the service is at least theoretically reachable) before alerting the caller that the service is "ready".
From a controller perspective it would also be nice to have
more-granular feedback (maybe an HS_DESC event that indicates "waiting X seconds to do anything at all with this one") so that e.g. a GUI can make a nice progress bar that doesn't just sit there (i.e. if tor tells me that it will be 5 seconds before we even try anything, I can provide feedback every 1 second if I like).
Perhaps you could achieve "less load on HSdirs" but preserve "at least one descriptor is uploaded right away" by selecting N random delays, where one lucky HSDir gets a 0 second delay and the other 5 get something random between 1 and 30 (or whatever).
p.s. I don't view ADD_ONION as being useful *only* for temporary services -- it's also the good API for applications that want to manage their own private-key material. For these, they might like to know when *all* descriptors are uploaded, etc.
meejah transcribed 2.0K bytes:
Ivan Markin twim@riseup.net writes:
IMO an onion service should publish its first descriptor instantly. If something happens afterwards and one has to fix the descriptor - deal with it with backoff/delay to prevent DoS on HSDirs.
+1
txtorcon only ever waits for the first descriptor to be published (since at this point I presume the service is at least theoretically reachable) before alerting the caller that the service is "ready".
From a controller perspective it would also be nice to have more-granular feedback (maybe an HS_DESC event that indicates "waiting X seconds to do anything at all with this one") so that e.g. a GUI can make a nice progress bar that doesn't just sit there (i.e. if tor tells me that it will be 5 seconds before we even try anything, I can provide feedback every 1 second if I like).
Similarly to teor's earlier response in this thread, the change to a 1s timer would be an easy patch (read: also a welcome patch!) which would likely see inclusion in 0.2.9 stable, accompanied by plausible arguments for inclusion. Given [insert handwavey "I'm not the person who does statistics/metrics around here"] that most ephemeral onion services are well-behaving, from txtorcon-using to stem-based things, to apps like ricochet which create onion services and then later reload them, the initial descriptor upload should be no overhead at all compared to a not-so-well-behaving service/app which e.g. uploads ten descriptors per second.
Perhaps you could achieve "less load on HSdirs" but preserve "at least one descriptor is uploaded right away" by selecting N random delays, where one lucky HSDir gets a 0 second delay and the other 5 get something random between 1 and 30 (or whatever).
Couldn't have a worrisome effect: that a client chooses the wrong HSDir several times (in the process of the onion service unluckily reporting delayed descriptors at precisely the wrong time w.r.t. the client)?
p.s. I don't view ADD_ONION as being useful *only* for temporary services -- it's also the good API for applications that want to manage their own private-key material. For these, they might like to know when *all* descriptors are uploaded, etc.
Again, improving the control port notification interface is much welcome, and patches are straightforward to review for timely inclusion.
Best regards,
Hi tor-dev@,
Ivan Markin:
IMO an onion service should publish its first descriptor instantly. If something happens afterwards and one has to fix the descriptor - deal with it with backoff/delay to prevent DoS on HSDirs. I think that most of the ephemeral services are not going to use more than one descriptor. Moreover, they are going to use just one introduction point. So it's not a big deal if one of the published IPs fails since a client is going to use one of the rest. Also note the reachability issue I mentioned.
teor:
It would be nice to have this change in 0.2.9 for Single Onion Services and I think also for HSs with OnionBalance
Can we actually have this in 029? If yes, how should we do it exactly?
This issue gets more and more annoying. Mostly because of the (un-)reachability issue.
-- Ivan Markin
On 27 Sep 2016, at 09:37, Ivan Markin twim@riseup.net wrote:
Hi tor-dev@,
Ivan Markin:
IMO an onion service should publish its first descriptor instantly. If something happens afterwards and one has to fix the descriptor - deal with it with backoff/delay to prevent DoS on HSDirs. I think that most of the ephemeral services are not going to use more than one descriptor. Moreover, they are going to use just one introduction point. So it's not a big deal if one of the published IPs fails since a client is going to use one of the rest. Also note the reachability issue I mentioned.
teor:
It would be nice to have this change in 0.2.9 for Single Onion Services and I think also for HSs with OnionBalance
Can we actually have this in 029? If yes, how should we do it exactly?
Submit a patch on the ticket that changes the interval to 5 seconds, and see if it gets accepted before the code freeze: https://trac.torproject.org/projects/tor/ticket/20082
It would help to come up with a reasoned argument why 5 seconds is better than 30 seconds, and why it can't possibly be any worse under any circumstances.
Alternately, write a patch to proposal 224 to specify 30 seconds, and wait for it to be implemented in 0.3.0 or 0.3.1.
Tim
This issue gets more and more annoying. Mostly because of the (un-)reachability issue.
-- Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
T
-- 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
teor:
Submit a patch on the ticket that changes the interval to 5 seconds, and see if it gets accepted before the code freeze: https://trac.torproject.org/projects/tor/ticket/20082
It would help to come up with a reasoned argument why 5 seconds is better than 30 seconds, and why it can't possibly be any worse under any circumstances.
Hmm, okay. I've created this ticket and submitted a patch there. :) I just lost the point of this discussion and what steps should be taken next with this delay.
-- Ivan Markin
On 29 Sep 2016, at 08:06, Ivan Markin twim@riseup.net wrote:
teor:
Submit a patch on the ticket that changes the interval to 5 seconds, and see if it gets accepted before the code freeze: https://trac.torproject.org/projects/tor/ticket/20082
It would help to come up with a reasoned argument why 5 seconds is better than 30 seconds, and why it can't possibly be any worse under any circumstances.
Hmm, okay. I've created this ticket and submitted a patch there. :) I just lost the point of this discussion and what steps should be taken next with this delay.
* agree on what we actually want to change * Ephemeral onion services' initial delay? * All onion services' initial delay?
I think we should change the initial delay for all onion services, otherwise we end up with inconsistent, confusing delays.
* make an argument for how the behaviour is better, and how it can't possibly cause problems (or is very unlikely to cause problems)
* get the patch reviewed and merged
T
-- 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
teor:
- 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
It would also improve the UX of Tails Server. It would be awesome if we could have this in 0.2.9.
Cheers
I've just tried the patch from ticket 20082 and it works great for me. I was actually wondering why it was taking so long for a ephemeral hidden service to get registered in my SIM4Things project (I register an ephemeral service first to get Tor to setup the introduction points, then re-register it a la OnionBalance with a new identity). It's definitely a great improvement for my project!
Razvan
On Wed, Sep 7, 2016 at 6:40 PM, Ivan Markin twim@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?
- Can we set it back to 5s thus avoiding issues that can arise after
removing the delay?
- Should we do something now or postpone it to prop224?
[1] https://trac.torproject.org/projects/tor/ticket/20082
Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
isis agora lovecruft -
Ivan Markin -
meejah -
Razvan Dragomirescu -
segfault -
teor