Opened 2 years ago

Closed 9 months ago

# Explain which cells are counted for onion service traffic graphs

Reported by: Owned by: teor metrics-team Medium Metrics/Statistics Normal

### Description

I can't work out what is being measured on the onion service traffic graph:
https://metrics.torproject.org/hidserv-rend-relayed-cells.html

Does it include:

• cells sent from rendezvous points to clients?
• cells sent from rendezvous points to services?
• cells sent to rendezvous points from clients?
• cells sent to rendezvous points from services?

Also, the related blog post says:
"A related statistic here is "How much of the Tor network is actually hidden service usage?". There are two different ways to answer this question…"

Does the graph try to answer this question?
Or is it just measuring rendezvous point traffic without counting the traffic on the relays on rest of the circuit?

## Child Tickets

### comment:1 Changed 2 years ago by arma

I believe the count is simply how many cells are handled at the rendezvous point. And handled means "received from one side and sent to the other side".

### comment:2 Changed 2 years ago by arma

And by "how many cells" I mean "how many cells on rendezvous circuits".

(In a sense this is a network team question, because they're the ones who wrote the code to collect and publish the number. The metrics team just takes the number and visualizes it.)

### comment:3 in reply to:  description Changed 2 years ago by teor

I can't work out what is being measured on the onion service traffic graph:
https://metrics.torproject.org/hidserv-rend-relayed-cells.html

Does it include:

• cells sent from rendezvous points to clients?
• cells sent from rendezvous points to services?
• cells sent to rendezvous points from clients?
• cells sent to rendezvous points from services?

I can answer this question from the tor code:

Tor reports the number of relay cells relayed by the rendezvous point.
(It doesn't report the circuit-level extend and destroy cells).

Using the same wording as the question:

• cells sent from clients to services via rendezvous points and
• cells sent from services to clients via rendezvous points

Also, the related blog post says:
"A related statistic here is "How much of the Tor network is actually hidden service usage?". There are two different ways to answer this question…"

Does the graph try to answer this question?

I don't think it does, but I'd need to look at the metrics code to confirm.

Or is it just measuring rendezvous point traffic without counting the traffic on the relays on rest of the circuit?

I'm going to assume that metrics makes no attempt to multiply the traffic by the number of relays in the circuit.

### comment:4 follow-up:  5 Changed 2 years ago by teor

Status: new → needs_review

I suggest we change:
"This graph shows the amount of onion-service traffic from version 2 and version 3 onion services in the network per day"
To:
"This graph shows the amount of onion-service traffic from version 2 and version 3 onion services relayed by rendezvous points per day"

I wonder if we should keep "per day", it's a bit confusing when the bandwidth is in Gigabits per second.

### comment:5 in reply to:  4 Changed 2 years ago by karsten

I suggest we change:
"This graph shows the amount of onion-service traffic from version 2 and version 3 onion services in the network per day"
To:
"This graph shows the amount of onion-service traffic from version 2 and version 3 onion services relayed by rendezvous points per day"

Sounds good.

Before I make this change, is there a good glossary entry for rendezvous point that we could link here? It's a technical term that deserves an explanation, and it's currently not contained in the metrics glossary. (We're likely going to merge glossaries at some point, but until we're there, let's borrow a definition from elsewhere.)

I wonder if we should keep "per day", it's a bit confusing when the bandwidth is in Gigabits per second.

Yes, that makes sense.

### comment:6 Changed 2 years ago by irl

From my perspective, it's best to add this for now to the metrics glossary as long as it's not disagreeing with a term in torspec's glossary. This way it will be included in my patch for torspec's glossary later. (Otherwise, I might not remember and it won't be included).

### comment:7 Changed 2 years ago by iwakeh

Status: needs_review → assigned

No objections to the changes stated in comments 4 and 5.
Assigning this to 'metrics-team' and changing state from 'need_review', so we know there is still a patch to be created.

### comment:8 Changed 9 months ago by karsten

Resolution: → fixed assigned → closed

Looks like all that was left was turning the comments above into a patch. This was trivial enough to not require yet another review, so pushed as commit 5cbb25e to master and deployed. Closing. Thanks!

Note: See TracTickets for help on using tickets.