[tor-relays] Inflated throughput measures from torproject metrics?

[Georg Koppen]

Hello!

torix via tor-relays:
> Dear Georg,
> 
> I don't understand that a ddos attack would affect bumping up the advertised bandwidth - or would it?  My Aramis family advertised bandwidth seems to have leveled off 2 days ago, but not gone down to previous levels. I noted the total advertised bandwidth of the Quetzalcoatl family over the past few days, and it still seems to be going up:2,391 2,442 2,598 and now 2,754.

If you hover of the Advertised Bandwidth of one of your relays on Relay
Search you'll see:

Bandwidth rate: XXX
Bandwidth burst: XXX
Observed bandwidth: XXX
.

You can configure the former two in your torrc file but the observed
bandwidth is actually taken from your relay itself: it's the max
bandwdith your relay used within 10 seconds (I am simplifying here a bit
but that's the reason why the flooding takes 20 sec: to be sure to hit
the 10 sec interval and affect the observed bandwidth).

Now, advertised bandwidth is the minimum of the three values. So, yes,
if someone actually tries to DDoS by sending lots of traffic the
observed bandwidth would go up and thus the advertised one (assuming
bandwidth rate and bandwidth burst have high values (which they have by
default) and the observed bandwidth is the limiting factor here).

> How the bwauths adjust the advertised bandwidth is a mystery to me.  My impression is that after the first few months the advertised bandwidth will settle in and stay the same.  Which is why this increase in advertised bandwidth starting Thursday seems so strange.

See the previous sections where I explained how the advertised bandwidth
is calculated. That said, bandwidth authorities do not adjust the
advertised bandwidth. That's solely done by your torrc configuration and
the 10 sec max throughput of your relay. What they *do* is taking the
advertised bandwidth into account when calculating the "final" bandwidth.

juga has made a good overview of the zoo of bandwidth related concepts a
while ago[1] if you want to start wrapping your head around that. :)

Hope this helps,
Georg

[1]
https://onbasca.readthedocs.io/en/latest/bandwidth_tor.html#bandwidth-values-origin

> --Torix
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Wednesday, September 1st, 2021 at 6:06 AM, Georg Koppen <gk at torproject.org> wrote:
> 
>> torix via tor-relays:
>>
>>> Thanks for setting my mind at ease, Georg. I did actually read about the speed test, but didn't think that could be the cause, as I weathered the last speed test without seeing anything noticeable.
>>>
>>> Reading the email again, I understand that the difference here is that the traffic script is being run over and over again for 2 weeks instead of just once. And yes, one of my relays fell over with a kernel limits problem two nights ago.
>>
>> Hrm. I wonder, though, whether that's actually related to the speed test
>>
>> or something else given that the flooding takes only 20 seconds. The
>>
>> overhead caused by the speed test should be in line with regular usage.
>>
>> See and older post[1] for more details about the experiment.
>>
>> Looking at onion service traffic for instance[2] it seems we might have
>>
>> some DDoS situation again. Maybe that caused issues for your relay (not
>>
>> sure which one was affected).
>>
>> Georg
>>
>> [1] https://lists.torproject.org/pipermail/tor-relays/2019-July/017535.html
>>
>> [2] https://metrics.torproject.org/hidserv-rend-relayed-cells.html
>>
>>> --Torix
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>
>>> On Monday, August 30th, 2021 at 7:15 AM, Georg Koppen gk at torproject.org wrote:
>>>
>>>> torix via tor-relays:
>>>>
>>>>> The advertized bandwidth of my aramis family of relays has gone up from around 45 to 67 total since last week. ZimmerLinux (quetzalcoatl) sees inflation as well. I found a graph here of quetzalcoatl:
>>>>>
>>>>> https://nusenu.github.io/OrNetStats/quetzalcoatl-relays.org.html
>>>>>
>>>>> which whose weekly graph currently shows everything staying the same until about Wed. 25 Aug., then creeping up. He hasn't added any relays, so it looks as though the bwauths have changed something.
>>>>>
>>>>> I'm bringing this up because something seems a little out of control here.
>>>>
>>>> This is to be expected due to the advertised bandwidth related network
>>>>
>>>> experiment that is currently running.[1][2]
>>>>
>>>> Georg
>>>>
>>>> [1]
>>>>
>>>> https://lists.torproject.org/pipermail/tor-relays/2021-August/019786.html
>>>>
>>>> [2] https://status.torproject.org/experiments/2021-08-26-relay-speed-test/
>>>>
>>>>> TIA,
>>>>>
>>>>> --Torix
>>>>>
>>>>> tor-relays mailing list
>>>>>
>>>>> tor-relays at lists.torproject.org
>>>>>
>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>>
>>>> tor-relays mailing list
>>>>
>>>> tor-relays at lists.torproject.org
>>>>
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>> tor-relays mailing list
>>>
>>> tor-relays at lists.torproject.org
>>>
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>> tor-relays mailing list
>>
>> tor-relays at lists.torproject.org
>>
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20210902/1920e91e/attachment-0001.sig>