#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs