#25854 closed defect (fixed)

Improve advertised/observed bandwidth mouseover text

Reported by: irl Owned by: irl
Priority: Medium Milestone:
Component: Metrics/Relay Search Version:
Severity: Normal Keywords:
Cc: metrics-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It should be clear whether this is a sum of in/out or just traffic relayed.

Child Tickets

Change History (7)

comment:1 Changed 11 months ago by karsten

Hmm? Anything I can help with?

comment:2 Changed 11 months ago by irl

The problem here is that dir-spec is not particularly clear on this, so probably some reading of the code is needed to make sure.

Someone asked in IRC whether this was the sum of the total bandwidth (directory fetches, relay traffic, client traffic) in and out, or whether this was just for traffic that is relayed, or relayed traffic + overhead just for relaying traffic (and then whether it's the total in+out or just total throughput).

comment:3 in reply to:  2 ; Changed 11 months ago by teor

Relay Search is currently ambiguous:

The volume of traffic, both incoming and outgoing, that the relay is willing to sustain, as configured by the operator and claimed to be observed from recent data transfers.

Replying to irl:

The problem here is that dir-spec is not particularly clear on this, so probably some reading of the code is needed to make sure.

I'll open a ticket to improve dir-spec, once we know what isn't clear.

Someone asked in IRC whether this was the sum of the total bandwidth (directory fetches, relay traffic, client traffic) in and out, or whether this was just for traffic that is relayed, or relayed traffic + overhead just for relaying traffic (and then whether it's the total in+out or just total throughput).

I answered a similar question for tjr in #tor-project a week or so ago. If anyone has the IRC backlog, they can get the full details.
I'll try to reconstruct it here.

This is what the spec currently says:

Estimated bandwidth for this router, in bytes per second. The
"average" bandwidth is the volume per second that the OR is willing to
sustain over long periods; the "burst" bandwidth is the volume that
the OR is willing to sustain in very short intervals. The "observed"
value is an estimate of the capacity this relay can handle. The
relay remembers the max bandwidth sustained output over any ten
second period in the past day, and another sustained input. The
"observed" value is the lesser of these two numbers.

https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n424

In other words, the spec says that:

  • average bandwidth limit is the maximum bandwidth the relay is willing to handle over long periods
  • burst bandwidth limit is the maximum bandwidth the relay is willing to handle over short periods
  • observed bandwidth rate is min(in, out) where in and out are the maximum bandwidths sustained inbound or outbound over any recent 10 second period over the last day

The spec isn't explicit about the direction of the traffic, except for observed bandwidth. Here is how Tor currently implements the bandwidth limits:

  • there is a token bucket for inbound traffic, and tor stops reading from the kernel once the bucket is empty
  • there is a token bucket for outbound traffic, and tor stops writing to the kernel once the bucket is empty

The difference between kernel and link-level traffic causes some interesting issues for people who are trying to get precise bandwidths. See, for example, #25687. Our general advice is "don't worry about that level of detail".

So there is a separate limit on both inbound and outbound traffic.
The effective relayed rate is min(in, out), and includes some overheads, just like the observed bandwidth.
We can update dir-spec to clarify this.

The spec also doesn't specify whether the bandwidth includes overheads, so you should assume that it does include some overheads, and it doesn't include others. In particular:

  • Recent tor versions include everything over an ORPort, whether it originates at the relay, is relayed for a client, or is sent to a client in response to a BEGINDIR request. We can update the spec to clarify this.
  • I'm not sure if Tor includes DirPort traffic. We could find out what tor does and specify it. But I'm not sure if this level of detail is relevant.
  • As far as I recall, Tor includes all cell packing overhead, but not TLS, TCP, IP, or link layer overhead. But I'm not sure if this level of detail is relevant.

Can you help me understand why you need to know details about overheads?
The exact overheads that are included will change over time as we improve Tor's code and statistics.

comment:4 Changed 11 months ago by teor

Oh, I forgot. If you want a simple amendment to your text, here is something to start with:

The volume of traffic that the relay is willing to sustain. The rate and burst limits apply separately to inbound and outbound traffic. The observed bandwidth is the minimum of recent inbound and outbound traffic, as reported by the relay.

comment:5 in reply to:  3 Changed 11 months ago by irl

Replying to teor:

Can you help me understand why you need to know details about overheads?
The exact overheads that are included will change over time as we improve Tor's code and statistics.

Mainly just to be precise about what it is we expect the numbers to represent, and to avoid ambiguity in the UI and documentation.

Thanks for the detailed response, hopefully will get to updating the text soon.

comment:6 Changed 11 months ago by irl

Cc: metrics-team added
Owner: changed from metrics-team to irl
Status: newaccepted

comment:7 Changed 10 months ago by irl

Resolution: fixed
Status: acceptedclosed

[master 41ca22f] Updates Bandwidth field mouseover description (Fixes: #25854)

Note: See TracTickets for help on using tickets.