Opened 7 years ago

Last modified 9 months ago

#7177 new project

Understand how accurate the bandwidth authority estimates are

Reported by: karsten Owned by:
Priority: Medium Milestone: sbws: unspecified
Component: Core Tor/sbws Version:
Severity: Normal Keywords:
Cc: mikeperry, aagbsn, ln5, gamambel, cass, juga Actual Points:
Parent ID: #25925 Points:
Reviewer: Sponsor:

Description

(Re-using text from Roger and Mike for this ticket description.)

It would be good to have a better understanding of how accurate the bandwidth authority estimates are. Why do some really fast relays get huge weights, and other really fast relays don't? Does it have to do with location of the measurers? What exactly is the trade-off between having fast nodes all nearby each other (and nearby the bandwidth authorities) in the network, and having nodes in geographically dispersed places?

We probably should figure out a way for the bandwidth authorities to utilize per-node as well as ambient circuit failure (#7023, #7037).

There's a bunch of related stuff for TCP socket exhaustion, too. All of it probably involves some fairly diligent monitoring of results and experimentation though.

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by karsten

Cc: ln5 added

comment:2 in reply to:  description Changed 7 years ago by aagbsn

Cc: gamambel added

Replying to karsten:

(Re-using text from Roger and Mike for this ticket description.)

It would be good to have a better understanding of how accurate the bandwidth authority estimates are. Why do some really fast relays get huge weights, and other really fast relays don't? Does it have to do with location of the measurers? What exactly is the trade-off between having fast nodes all nearby each other (and nearby the bandwidth authorities) in the network, and having nodes in geographically dispersed places?

Can we come up with a list of "really fast relays" that don't have huge weights? I've seen an exit operator complain that his/her exit in the same datacenter as another exit does not see similar performance [1]. I'd guess that this means it's probably a difference in the exit configuration rather than geographic location, and since the faster relay was operated by torservers.net I pointed the operator at their wiki which contains more details about the server configuration (e.g., tcp stack tuning)[2]. Maybe we can simulate circuits of varying latency and see how these tunables affect results?

[1] https://lists.torproject.org/pipermail/tor-relays/2012-October/001689.html
[2] https://www.torservers.net/wiki/setup/server#high_bandwidth_tweaks_100_mbps

We probably should figure out a way for the bandwidth authorities to utilize per-node as well as ambient circuit failure (#7023, #7037).

There's a bunch of related stuff for TCP socket exhaustion, too. All of it probably involves some fairly diligent monitoring of results and experimentation though.

comment:3 Changed 3 years ago by cass

Cc: cass added
Severity: Normal

This ticket is tagged SponsorZ, but it looks like progress stalled four years ago. Is this still an active issue that needs funding?

comment:4 Changed 3 years ago by karsten

Keywords: SponsorZ removed

This sounds like it should be part of a larger project to improve the bandwidth authority code. Funding for this ticket alone doesn't make much sense. Removing the SponsorZ keyword. Thanks for asking.

comment:5 Changed 22 months ago by teor

Parent ID: #13630

See #13630 for a torflow replacement, and #24045 for some analysis by metrics in the meantime.

comment:6 Changed 22 months ago by teor

Priorities and Severities in torflow are meaningless, setting them all to Medium/Normal.

comment:7 Changed 22 months ago by teor

Owner: aagbsn deleted
Status: newassigned

aagbsn was the default owner, unassigning

comment:8 Changed 20 months ago by teor

Status: assignednew

Mark all tickets that are assigned to nobody as "new".

comment:9 Changed 16 months ago by juga

Cc: juga added

comment:10 Changed 16 months ago by juga

Parent ID: #1363025925

comment:11 Changed 16 months ago by juga

Parent ID: 25925#25925

comment:12 Changed 9 months ago by teor

Component: Core Tor/TorflowCore Tor/sbws

comment:13 Changed 9 months ago by teor

Milestone: sbws: unspecified
Note: See TracTickets for help on using tickets.