Opened 8 years ago

Closed 8 years ago

#4387 closed task (fixed)

How much GB does a useful relay push per week?

Reported by: runa Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

As part of #3574, we estimated that a useful bridge should push around 10GB a week. Do you have similar numbers for a relay?

This is related to the Tor Cloud, so I'm choosing that as the component. Feel free to change it to something else.

Child Tickets

Change History (4)

comment:1 Changed 8 years ago by karsten

Component: Tor CloudAnalysis

(Changing the component to Analysis which fits better IMO.)

The analysis how much traffic a bridge should be able to push per week to be useful is different from this analysis. Bridges are chosen more or less uniformly, or at least not dependent on their bandwidth. The idea of the analysis was to make sure that a cloud bridge, that is chosen with the same probability as non-bandwidth-limited bridges, has enough bandwidth to serve at least an average number of users. If there are potentially lots of cloud bridges with a certain bandwidth setting, they shouldn't be useless by design.

The situation is different for relays. Relays are chosen based on their bandwidth capacity, among other things. A relay is the more useful the more bandwidth it has. Maybe there's a bandwidth limit below which it's not worth including a relay in the consensus, because it would only bloat the directory and keep the bandwidth scanners busy. But I don't think we're looking for that number here. (You don't want to create cloud relays that have just enough bandwidth that we don't want to throw them out of the network, right?)

Here's a somewhat different analysis that may or may not answer your question: how much bandwidth does an average relay push per week? If you configure a cloud relay to push this much bandwidth you'll end up with an average relay. Whether that's a useful relay or not is a different question. It probably is, but a relay with fewer bandwidth might already be useful, too.

And here are the results: The total bandwidth pushed by all relays during one week (October 28 to November 3) was 583 TiB/wk or 0.99 GiB/s. There were on average 2375 relays in the consensus during that time. Hence, an average relay pushed 251 GiB/wk or 436 KiB/s.

So, I could imagine that a cloud relay pushing 436 KiB/s would be useful, but at the same time too expensive. A cloud relay with half or a quarter of that bandwidth would probably be useful, too. But that's not a question I can answer using statistics.

Maybe we should turn the question around: What's the maximum bandwidth that a cloud relay can push per week before becoming crazy expensive? If it costs ten times the amount to run a cloud relay that pushes one tenth of the bandwidth that a rented virtual server pushes, maybe it's a bad idea to offer cloud relays. (Also consider the development effort required to offer and maintain cloud relays.)

comment:2 in reply to:  1 ; Changed 8 years ago by runa

Replying to karsten:

And here are the results: The total bandwidth pushed by all relays during one week (October 28 to November 3) was 583 TiB/wk or 0.99 GiB/s. There were on average 2375 relays in the consensus during that time. Hence, an average relay pushed 251 GiB/wk or 436 KiB/s.

Ok, definitely not something we want to put into the cloud at this point.

Maybe we should turn the question around: What's the maximum bandwidth that a cloud relay can push per week before becoming crazy expensive? If it costs ten times the amount to run a cloud relay that pushes one tenth of the bandwidth that a rented virtual server pushes, maybe it's a bad idea to offer cloud relays. (Also consider the development effort required to offer and maintain cloud relays.)

It sounds like running a relay in the cloud is going to be too expensive. I do agree that we should look into just how much a cloud relay can push per week before becoming crazy expensive, though.

As for development effort; creating and maintaining cloud relay images will not require a lot of time, so this will not block anything.

comment:3 in reply to:  2 ; Changed 8 years ago by karsten

Replying to runa:

It sounds like running a relay in the cloud is going to be too expensive. I do agree that we should look into just how much a cloud relay can push per week before becoming crazy expensive, though.

That sounds like it wants a new ticket (this time in the Tor Cloud component).

Is your question about how much bandwidth a useful/average relay pushes per week answered? If so, can you close this ticket?

As for development effort; creating and maintaining cloud relay images will not require a lot of time, so this will not block anything.

But it will require some time. It's yet another product that will make people unhappy when we decide we're lacking the time to maintain it. If people ask why there's no cloud relay image, let's tell them the expected bandwidth cost per week and they'll understand.

comment:4 in reply to:  3 Changed 8 years ago by runa

Resolution: fixed
Status: newclosed

Replying to karsten:

Replying to runa:

It sounds like running a relay in the cloud is going to be too expensive. I do agree that we should look into just how much a cloud relay can push per week before becoming crazy expensive, though.

That sounds like it wants a new ticket (this time in the Tor Cloud component).

I'll create one when/if a lot of people start asking for cloud relay images.

Is your question about how much bandwidth a useful/average relay pushes per week answered? If so, can you close this ticket?

Yes, thanks!

As for development effort; creating and maintaining cloud relay images will not require a lot of time, so this will not block anything.

But it will require some time. It's yet another product that will make people unhappy when we decide we're lacking the time to maintain it. If people ask why there's no cloud relay image, let's tell them the expected bandwidth cost per week and they'll understand.

Yep, agreed.

Note: See TracTickets for help on using tickets.