Opened 6 years ago

Last modified 9 months ago

#7509 new enhancement

Publish and use circuit success rates in extrainfo descriptors

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: privcount, mumble-feature, tor-relay needs-design statistics metrics
Cc: arma, aagbsn@… Actual Points:
Parent ID: #5456 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (10)

comment:1 in reply to:  description ; Changed 6 years ago by aagbsn

Replying to mikeperry:

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.

I guess you mean that each relay publishes the average circuit success rate within a time window for all circuits, and not each edge (the success rate per relay).

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?

Could you elaborate a bit here? What graph is being traversed?

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.

Perhaps you don't need each relay to report success rates for every relay it sees, but instead a (randomly selected?) subset?

Either way, an extrainfo-based approach may end up being simpler to implement than a centralized scanner for reliably measuring circuit failure (see #7281).

Perhaps it's worth doing both?

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.

comment:2 in reply to:  1 Changed 6 years ago by arma

Replying to aagbsn:

Replying to mikeperry:

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.

I guess you mean that each relay publishes the average circuit success rate within a time window for all circuits, and not each edge (the success rate per relay).

That's what I meant. Actually, I didn't suggest to publish the success rate, but rather the numerator and denominator of the rate.

If we want to have some opinion about the rest of the network, maybe each relay could publish the success numbers of create cells it passed along to others, too? So, each relay would be publishing four numbers in its extra-info desc.

Perhaps it's worth doing both?

That's usually the case.

comment:3 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:4 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:5 Changed 4 years ago by aagbsn

Cc: aagbsn@… added

comment:6 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:7 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:8 Changed 21 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:9 Changed 21 months ago by nickm

Keywords: needs-design statistics metrics added
Severity: Normal

comment:10 Changed 9 months ago by teor

Keywords: privcount added
Note: See TracTickets for help on using tickets.