Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:25:06Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7509Publish and use circuit success rates in extrainfo descriptors2020-06-13T14:25:06ZMike PerryPublish and use circuit success rates in extrainfo descriptorsarma suggests we publish create cell success rates in the extrainfo descriptors. We want to use these values to measure the actual rate of client circuit success network wide given our current path selection weights.
In this simple case...arma suggests we publish create cell success rates in the extrainfo descriptors. We want to use these values to measure the actual rate of client circuit success network wide given our current path selection weights.
In this simple case, a graph traversal computation would do the trick, but ideally we want to do it in a way that is liar-resistant. Does this mean we should publish information on our observed peers' rates of CREATE success instead?
Perhaps this can be modeled as an eigenvalue problem, a-la eigenspeed (#5464). Since we're computing only a single scalar value for the whole network at the end as opposed to a vector of weights, there might be a simplification we could deploy that reduces the amount of stuff we need to shove into extrainfo.
Either way, an extrainfo-based approach may end up being simpler to implement than a centralized scanner for reliably measuring circuit failure (see #7281).
I'm not sure I trust a fully self-reported scheme more without some kind of liar resistance, but it might end up that doing the graph traversal already bakes in as much liar resistance as you'd get from having each node report on its peers. It might be possible to prove this even, but something tells me empirical simulation is as close as we're going to get.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7281Bandwidth auths should publish average and weighted onionskin failure rates2020-06-13T16:19:06ZMike PerryBandwidth auths should publish average and weighted onionskin failure ratesWhile testing for path bias rates, I've noticed that the onionskin failure rate in the network can vary as much as +/- 30% in the matter of a few hours. This is rather insane.
We should publish statistics on this failure rate over time ...While testing for path bias rates, I've noticed that the onionskin failure rate in the network can vary as much as +/- 30% in the matter of a few hours. This is rather insane.
We should publish statistics on this failure rate over time somehow. This might be a metrics task, but if the bandwidth auths do it, we can have them set consensus parameters for the path bias code to decide on how loudly to scream and when (see Proposal 209).
For that, I think I want network-wide averages, as well as consensus-bandwidth weighted averages. The path bias levels should be set using consensus-bandwidth weighted values.
See also #5457, but I don't think we should do that anymore, based on how easy it seems to be to cause onionskin overload.https://gitlab.torproject.org/legacy/trac/-/issues/1889Contradictory bandwidth reports in overlapping extra-info descriptors2020-06-13T14:06:14ZRobert HoganContradictory bandwidth reports in overlapping extra-info descriptorsOn a randomly sampled day in July there were 2000+ cases where the bw reported by extra-info for a given timeslice on a router was two different measurements, depending on which extra-info descriptor you looked at.
Here is an example in...On a randomly sampled day in July there were 2000+ cases where the bw reported by extra-info for a given timeslice on a router was two different measurements, depending on which extra-info descriptor you looked at.
Here is an example in the read history for relay Pounet27TorRelay:
BW NOT EQUAL for 2010-07-30T02:31. Is 439296 : Was 4738048
read-history 2010-07-30 21:46:14 (900 s) 11229184,13546496,11268096,13392896,16567296,9265152,6163456,4869120,8190976,0,0,0,0,0,0,0,0,0,734208,439296,0,0,0,0,0,0,0,0,0,6400000,11721728,12796928,12404736,14963712,13637632,11209728,12163072,10721280,6233088,10669056,9666560,9474048,11543552,11773952,10487808,10580992,10299392,13220864,12548096,11171840,7584768,4970496,3948544,2686976,4140032,4179968,4777984,8782848,9647104,9838592,13700096,10819584,11526144,9906176,14349312,12468224,13254656,8672256,5794816,7155712,3275776,3682304,3339264,6937600,6926336,7901184,8549376,10533888,7639040,9754624,6426624,4097024,5630976,4674560,5093376,6675456,4874240,5531648,3744768,6883328,9871360,11807744,11097088,9028608,9231360,9802752
read-history 2010-07-30 04:46:14 (900 s) 8813568,8123392,9978880,8428544,9339904,6733824,9417728,11633664,11225088,9106432,11148288,7831552,11962368,9401344,8095744,8654848,9501696,7830528,6435840,8958976,4248576,4089856,4747264,6569984,4973568,2717696,5286912,0,0,1968128,0,0,0,0,0,0,0,0,0,2446336,5278720,6597632,4627456,7857152,7080960,8280064,5863424,7086080,5991424,2252800,1883136,5161984,3418112,4377600,3938304,6874112,5746688,2485248,3495936,4019200,6891520,3680256,4489216,4912128,3629056,1320960,7661568,11542528,11229184,13546496,11268096,13392896,16567296,9265152,6163456,4869120,8190976,0,0,0,0,0,0,0,0,0,245760,4738048,5920768,3057664,4745216,6483968,5610496,5480448,5497856,5471232
The difference starts after the zeros in the following sequence in each extra-info:
21:46: 11229184,13546496,11268096,13392896,16567296,9265152,6163456,4869120,8190976,0,0,0,0,0,0,0,0,0,245760,4738048
04:46: 11229184,13546496,11268096,13392896,16567296,9265152,6163456,4869120,8190976,0,0,0,0,0,0,0,0,0,734208,439296
I need to characterize the samples I have better to see if there's a pattern but any idea why this might happen?Tor: unspecified