Re: [or-cvs] r9993: Describe a simpler implementation for proposal 108, and note (in tor/trunk: . doc/spec/proposals)

• To: or-dev@xxxxxxxxxxxxx
• Subject: Re: [or-cvs] r9993: Describe a simpler implementation for proposal 108, and note (in tor/trunk: . doc/spec/proposals)
• Date: Fri, 27 Apr 2007 15:53:04 -0400
• Delivered-to: archiver@seul.org
• Delivered-to: or-dev-outgoing@seul.org
• Delivered-to: or-dev@seul.org
• Delivery-date: Fri, 27 Apr 2007 15:53:30 -0400
• Openpgp: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x57C89443
• References: <20070420171715.1B35A1408DE4@moria.seul.org> <20070425191628.GZ28282@moria.seul.org> <20070427154945.GW22999@totoro.wangafu.net>
• Sender: owner-or-dev@xxxxxxxxxxxxx
• User-agent: Thunderbird 1.5.0.9 (Macintosh/20061207)

> Actually, I chose "up for an entire day" as a minimum quantum for a
> reason.  The main problem with router instability isn't the fraction
> of time it's down; if you try to connect to a router that isn't there,
> that's not a big deal.  The problem with router instability is the
> likelihood that it will _go_ down and drop all your circuits.
Why not compute the probability that the router will go down in the next
10 minutes based on 5 days worth of data? This dependent the number of
transitions in ten minutes on average and that is easy to compute. If we
want to discount the past we could "erase" transitions, that is count
\alpha of a transition for two days ago, \alpha^2 of a transition for
three days ago, etc.