[tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

[Tor Bug Tracker & Wiki]

#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-------------------------------------+------------------------------------
 Reporter:  dgoulet                  |          Owner:  dgoulet
     Type:  defect                   |         Status:  needs_revision
 Priority:  Medium                   |      Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor             |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  tor-dirauth 043-should?  |  Actual Points:
Parent ID:  #33018                   |         Points:  0.4
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------------

Comment (by arma):

 I have been running this patch on moria1 lately, with an additional patch
 where I send a 503 response to vanilla-flavored consensus fetches, or old-
 style descriptor fetches, if they're not from a dir auth or relay address,
 even if I otherwise have enough bandwidth to answer them.

 With both patches in place, moria's outbound traffic has gone from
 200-500mbit/s down to 10-40mbit/s.

 Here are some stats from a one hour period (1400 to 1500 EST):

 ----
 == Dir auth requests ==

 I whitelisted 13 dirport connections from dir auths during this time:
 {{{
 Jan 24 14:18:32.445 [notice] Prioritizing dir auth response
 Jan 24 14:31:28.374 [notice] Prioritizing dir auth response
 Jan 24 14:50:03.921 [notice] Prioritizing dir auth response
 Jan 24 14:50:04.452 [notice] Prioritizing dir auth response
 Jan 24 14:50:04.836 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.016 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.261 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.458 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.575 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.697 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.808 [notice] Prioritizing dir auth response
 Jan 24 14:50:07.510 [notice] Prioritizing dir auth response
 Jan 24 14:50:09.915 [notice] Prioritizing dir auth response
 }}}
 Looking through the logs, these are all for /extra/d or server/d, i.e.
 old-style descriptors. Most of them occur a little bit after :50, which
 makes sense because that would be when those other dir auths discovered
 new descriptors from the vote I just sent them.

 ----
 == Relay requests ==

 I whitelisted 847 dirport requests from relay addresses during this
 period. Of these, 763 of them happened in the first half of the period
 (:00 through :30), which makes sense because fetch-extra-early tries to
 get a cached copy of the consensus in place before clients start asking
 for it. Accounting for a bit of time skew, 830 of the 847 happened between
 :00 and :33.

 Spot-checking these fetches, every single one of them that I looked at was
 a fetch for /micro/d, i.e. fetching a new microdescriptor. That's weird! I
 would have thought many of them would be fetching a microdesc-flavored
 consensus. I wonder if I am failing to log those, or if the process of
 answering them bypasses global_write_bucket_low().

 ----
 == Non-relay requests ==

 I sent back 110818 "503" responses during this hour (i.e. averaging over
 thirty "503" responses per second).

 Of those, 105452 were for "network status lists":
 Jan 24 14:00:00.038 [info] handle_get_current_consensus(): Client asked
 for network status lists, but we've been writing too many bytes lately.
 Sending 503 Dir busy.
 which I think is almost entirely requests to

 And the remaining 5366 were for "server descriptors":
 Jan 24 14:00:02.387 [info] handle_get_descriptor(): Client asked for
 server descriptors, but we've been writing too many bytes lately. Sending
 503 Dir busy.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33029#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online