Opened 4 months ago

Last modified 3 months ago

#22741 needs_revision enhancement

Make a tool that sends bandwidth to relays stuck with low measurements

Reported by: teor Owned by: aagbsn
Priority: Medium Milestone:
Component: Core Tor/Torflow Version:
Severity: Normal Keywords: bwauth bandwidth tor-relay
Cc: Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description

Some relays get stuck in a low bandwidth authority bucket, and never get out. And their self-measurement isn't enough to unstick them (#22453).

So we want a tool that sends traffic through relays with low consensus weight, ideally enough to guarantee them the Fast flag (at which point, the client bandwidth allocation and network measurement take over).

It would be nice to just send drop cells.

But I think we can do this using stem and tor and some URL downloading library.

Sticking this in "Torflow" because that's where it might end up.
But maybe it would be better in its own component eventually.

Child Tickets

Attachments (2)

list_boostable_relays.py (2.1 KB) - added by teor 4 months ago.
trial_20170629.sh (80.5 KB) - added by teor 4 months ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 4 months ago by teor

Our current plan is to use a path like this:
C -> M -> ES

Where:

  • C is the client running this code (call it dopiaza = two onions)
  • M is the relay we want to boost
  • ES is an Exit that only exits to its co-located HTTP Server with a single N MB file
  • N is 10*(the observed bandwidth we want the relay to have), we like 10 MB P(1000 consensus weight) at the moment

We can have a 15 second timeout, which allows 5 seconds for establishment, and 10 seconds for the relay to return some data.

And we should probably only boost relays that are:

  • below 1000 consensus weight (they don't get much client usage),
  • below 1000 observed bandwidth (they don't see much bandwidth),
  • have an advertised bandwidth rate of 1000 or above (they want some bandwidth),
  • observing below half their advertised bandwidth rate (limit) (they want extra bandwidth).

There are currently 619 relays that fit these criteria (~10% of the network).

comment:2 Changed 4 months ago by teor

arma and I tried to boost some relays with commands like this:

#  10485760      66135          1 False niwaniwator 67427B7271E6268599177A1B47C03DD3BB2439A6
curl --connect-timeout 5 --max-time 20 -X GET --data-binary @15MB http://126.70.7.146:9030/tor/server/authority.z > /dev/null &
curl --connect-timeout 5 --max-time 20 http://126.70.7.146:9030/tor/server/all.z http://219.117.225.36:80/tor/server/all.z > /dev/null

But they didn't seem to make the relays repost their descriptors, for one of two reasons:

  • most slow relays really are that slow, and
  • we don't know if DirPort bytes count in rephist (they seem to in the code, but we're not sure).

comment:3 in reply to:  2 Changed 4 months ago by teor

Replying to teor:

We think it might have worked on this relay, which is new:
https://atlas.torproject.org/#details/005DB7EE36E6DA6C7E178B0C36BE8794C1072720

But they didn't seem to make the relays repost their descriptors, for one of two reasons:

  • most slow relays really are that slow, and

This seems to be true for most relays below 1000 consensus weight.

  • we don't know if DirPort bytes count in rephist (they seem to in the code, but we're not sure).

I think they do count.

But they were delayed because relays take up to 4 hours to notice when these numbers have gone up, because that's the current NUM_SECS_BW_SUM_INTERVAL.

We're trying it on 100 of the slowest relays. I'll attach the selection script and trial list / script.

Changed 4 months ago by teor

Attachment: list_boostable_relays.py added

Changed 4 months ago by teor

Attachment: trial_20170629.sh added

comment:4 Changed 4 months ago by teor

Status: newneeds_revision

I'll revise these when I get time.

comment:5 Changed 3 months ago by teor

Unless we want to continue abusing the directory protocol, we will need to run a tor client to do this, or wait until stem gets ORPort support (#18856).

Note: See TracTickets for help on using tickets.