Over the last several days, a server nicknamed "mnl" has been posting descriptor updates bearing highly suspect data rate information. I have contacted the person at the contact-info address, so he is aware that the observed data rate (misnamed "bandwidth") reported in mnl's server descriptor is probably inaccurate by a factor of 10 or greater. His server has been up for over a month, and IIRC, is usually a relay with a very high data rate and therefore to be considered a significant benefit to the tor network's overall performance. However, mnl has lately been claiming to have had ten-second peak rates on the order of eight to ten times the peak rates typically published by blutmagie, the extraordinarily high-rate server that is nearly always a big chunk of the tor network capacity's foundation. Here is the latest of mnl's descriptors from my cached-descriptors file:
router mnl 159.149.71.27 9001 0 9030 platform Tor 0.2.0.30 (r15956) on Linux i686 opt protocols Link 1 2 Circuit 1 published 2008-09-08 14:41:50 opt fingerprint ABD3 8668 D3F4 76F5 0232 FEC0 B6DB 6550 EA43 EDD0 uptime 2781643 bandwidth 5242880 10485760 52239166 ^^^^^^^^ ---> ~48.8 MB/s (!) opt extra-info-digest 791494258CFA222ABCA7CD60D41CBFA108275E36 onion-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBAMZ7P0H3/DUwp/L1+eLx9CZlq8ZYh0vmcI4fA/5IzL4xld0/zOUGBXgI QVv9qKaLOWB5ljn/LH/cyW2zW/mfJAURyZd00ffbsmA76QEJuJldzgOMQVrVZQwA +QZCMh2+CgyvHhyyim9gFDsNHbkJQFbdX9hW3//sAMI0Oc4Lp+T7AgMBAAE= -----END RSA PUBLIC KEY----- signing-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBANo7EyYEVcDchLG30pHczPvjC9nB3pwn7CMo2vsa1uuXmvi5Kil1W6go KhQDvbowfe2TpjMRMxCZ2o02+dmRUQrgwCVZeKqlIbAfbMUpxuB6wCl352nNK6uT v6cgGNd5cd5aXZN1TVPkVlohi8h9cekDjrWhUu0lIz4GftOQviGxAgMBAAE= -----END RSA PUBLIC KEY----- contact [EMAIL PROTECTED] reject *:* router-signature -----BEGIN SIGNATURE----- YBaKbNNJXSVVuqGTlLRwAAdp1GHdRpGCQwiM5j6ws2Z2W13nbPHUk7PyKJ/3pMEl EYeVtP1P9G+Hc0ItoC2CmdREDnz/R5I9M9uNG+bHdD1lea/oyQRD6WXMczDFwrvs 54XpWr/MRUXyN0mF5hq8AtHU3NcL6Do4kXXnO9/6m+8= -----END SIGNATURE----- Nearly 49 MB/s seems a bit of a stretch. The server's operator sent me a note saying that the server is attached to the 1 GB/s campus backbone net, but it is attached via a 100 Mb/s router, so the reported data rate is four to five times the rate physically possible due to the router's limitation. The server, according to its operator, is running on a 2.6 GHz P4, and its descriptor says the machine is running LINUX. Based upon postings quite a while back from blutmagie's operator and from a few other operators of very high-data-rate servers, it seems to me that a 2.6 GHz P4 (Northwood?) running LINUX would not be capable of handling a load eight to ten times that of blutmagie, regardless of its network connection's capacity. All of the above leads me to suspect two things. One is that there may be some bug triggered only under exceedingly odd conditions that leads to reporting of data rates grossly out of line with reality. The second is that when a server claims such disproportionately high capacity, the overall performance of the tor server network can be compromised. This would happen due to the statistical method used for selecting nodes to be ussed to construct a circuit, which is partially based upon reported, recent (i.e., in the preceding 24 hours), peak data rates. In other words, a server reporting wildly high data rates distorts the PDF, such that an inordinately high fraction of circuit routes worldwide will include that server, regardless of whether that server can actually keep up with that workload. If circuits fail or fail to be built as a result of the overallocated errant server being in those circuits' routes, the effect is merely to reduce to networkwide total capacity of the tor network. That brings us back to something I've already posted on OR-TALK, namely, the apparent slowdown in tor traffic that has reduced the traffic through my tor server by at least 30% and, judging from the reduced peaks shown for a lot of the high-volume servers listed on the torstatus page, the tor network at large. If this is actually what has been going on, then not only should the bug be tracked down and killed ASAP, it serves as a call to rethink the method of circuit route selection to find ways to prevent a reduction-in-throughput attack that could be made by almost any creep by setting up a corrupted relay. (mnl is not even an exit.) (deep breath) I want to state right now that I do not in any way whatsoever suspect mnl's operator of any nefarious activity. I believe that he is at least as perplexed over his server's behavior as I am, especially given other information he provided about events over the weekend. I do not have a clue what sort of bug in tor could cause a server to begin reporting exaggerated data rates, but the majority of bugs fixed by Roger, Nick, et al. are ones that I would never have imagined either. Something weird is going on, and we both want it figured out. This note is intended as a loud cry for comment. I want urgently to be told how I have it all wrong, am hysterical over nothing, that the current tor network slowdown is due to something else (e.g., greatly reduced user demand), and that the tor network is not vulnerable in the aforedescribed manner. Thanks in advance for any reassurance anyone can provide. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************