[tor-scaling] Tuning KIST and EWMA parameters

teor teor at riseup.net
Sun Jun 9 02:38:56 UTC 2019


> On 9 Jun 2019, at 10:10, Mike Perry <mikeperry at torproject.org> wrote:
> 
> Rob Jansen:>> On Jun 7, 2019, at 8:18 AM, David Goulet
> <dgoulet at torproject.org> wrote:
>>> 
>>> So it appears that we might want to do a tor release with KISTSchedRunInterval
>>> being different values for client and relays? Or just tell the world to use
>>> "2msec" for their onion service but that won't work well...
>> 
>> Please, please, please let's first fix the off-by-one bug so that "KISTSchedRunInterval 2 msec" does not really mean "KISTSchedRunInterval 1 msec"..
> See LTS discussion: the fix you are requesting means that we can't
> update the consensus parameter in a controlled way until February 2022
> (see also
> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases).
> 
> So, to keep things expedient, please please please please please try to
> find ways not to require such delay. Don't panic! We are tuning features
> that have supposedly been subject to sufficient experimental rigor already.
> 
> Good point of order, also: for performance tuning, anything that
> requires relay patching is out. That stuff belongs in the "Develop"
> column of the kanban (and I can add it there, but not for cases like this).
> 
>> and so "KISTSchedRunInterval 1 msec" doesn't cause an infinite loop (or whatever the buggy behavior is).
> 
> "Doctor, it hurts when I--"
> 
> "Don't do that, then."
> 
> "Doctor, I don't know what might hurt!"
> 
> "Try to guess; otherwise, stop when it hurts."

We can definitely fix infinite loop bugs in tor.
But we can't change the meaning of any working values of the parameter.

So we can make relays warn and ignore "KISTSchedRunInterval 1".
Or warn and adjust "KISTSchedRunInterval 1" to "KISTSchedRunInterval 2".

And we can make authorities warn and adjust "KISTSchedRunInterval 1"
to "KISTSchedRunInterval 2".

Those changes would be compatible with LTS, because the LTS behaviour
is to hang the tor process. And that's a bug we should fix and backport.

Is there a ticket for this bug?

T 


More information about the tor-scaling mailing list