On Mon, Jul 11, 2016 at 12:41 PM, isis agora lovecruft <[email protected]> wrote: > Nick Mathewson transcribed 1.1K bytes: >> > > Various questions and responses to the meeting logs [0]: > > 1. I'm not sure I understand the difference between USABLE_FILTERED_GUARD and > CONFIRMED_GUARDS.
USABLE_FILTERED_GUARDS is a subset of FILTERED_GUARDS where "is running" is "yes" or "maybe". > 2. It seems like USED_GUARDS and CONFIRMED_GUARDS are being used > interchangeably. I realise that Nick at some point in IRC mentions the > former was renamed to the latter, but it isn't consistent and with so many > variables I'm finding myself a bit confused. Right. CONFIRMED_GUARDS is the new name for USED_GUARDS. I should replace every instance of the old. > 3. From: > >> 14:14:41 <nickm> (There is also a secret novelty in how it handles bridges >> and entrynodes) > > I don't actually see EntryNodes mentioned in the proposal? Appendix A.2 ? > 4. How were all the parameters in §A.1 [1] chosen? Did we simulate the > algorithm yet and fuzz the parameters under different network conditions > like we did before? All were totally pulled out of thin air, or out of the previous iteration of the proposal. > 5. For > >> 14:22:11 <nickm> #action try to think of ways that the "don't add to >> USED_GUARDS till we use it" rule can be manipulated by an >> attacker > > I assume the function governing membership in the set of FILTERED_GUARDS > pushes old/stale/less-usable/less-good guards out of the set when new ones > are found? That is, the size of FILTERED_GUARDS can't just grow > indefinitely, right? FILTERED_GUARDS can only grow up to the size of SAMPLED_GUARDS; but the size of SAMPLED_GUARDS is limited by MAX_SAMPLE_THRESHOLD. > 6. For "treating primariness as a continuum", do you mean that we > should assign some float values to a bunch of guards we're trying > all in parallel, then pick the guard that succeeded that had the > highest value? I worry a bit that this would complicate the code > and potentially result in many attempted connected to substantially > less-suitable nodes. It would mean that instead of treating the first N_PRIMARY_GUARDS members of CONFIRMED_GUARDS as 100% primary, and the remaining members as 0% primary, we would somehow treat the i'th gmember of CONFIRMED_GUARDS as f(i)% primary for some f. Right now "primariness" is used for several things: we'd need to look at which of these should look at a boolean, and which could instead look at a continuous variable. I do not yet know whether this is a good idea. > [0]: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-07-07-13.59.log.html > [1]: > https://trac.torproject.org/projects/tor/attachment/ticket/19468/prop259-redux-v3.txt#L414 > > -- > ♥Ⓐ isis agora lovecruft > _________________________________________________________ > OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 > Current Keys: https://fyb.patternsinthevoid.net/isis.txt cheers, -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
