[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30420 [Core Tor/Tor]: Should we recommend that relay operators turn on tcp bbr?
#30420: Should we recommend that relay operators turn on tcp bbr?
-----------------------------------------+---------------------------------
Reporter: arma | Owner: (none)
Type: task | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version: Tor:
| unspecified
Severity: Normal | Resolution:
Keywords: network-health, performance | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------------------+---------------------------------
Comment (by irl):
The fairness issue is also a problem with relays because relays will have
multiple connections to other relays. If some of those flows are using BBR
and some are not, the ones that are will starve out the ones that are not,
and will even starve out each other. This would cause relay->relay
available bandwidth to vary based on *which* other relays are sending
traffic, not just based on how much other traffic is coming into a relay.
My understanding here, based on conversations with knowledgeable
researchers, is that it would be a really bad idea to enable BBR. It's
used by Google for YouTube, which is probably why there is hype and
tutorials, etc. but it's designed with the YouTube use case in mind. The
bottleneck on all the connections will be at the user and a user will only
watch one YouTube video at a time. This is not our use case.
We might revisit this with BBR2, which is meant to solve the fairness
issue.
There are things that have been happening that we haven't really paid much
attention to so far that could be negatively affecting users on
restricted/impaired networks like IW10 (another Google thing). That's an
issue on the TCP connection from client->guard though not relay->relay.
BBR for client->guard might actually be a really good idea, assuming that
there is only one Tor user behind each bottleneck for each client
connection.
Google will also maintain databases of which IP ranges support which
speeds, etc. and then adapt congestion control and other properties to
give the best performance for that user. We cannot do that, we have no
fallback when something like BBR gives poor performance. I think it is
more important to raise the baseline performance than it is to focus on
getting the best performance to the users that are already using the best
connections.
This is yet another use case for a WAN testbed, and we should keep that in
mind, along with testing TCP extensions like ECN and alternate transports
altogether.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30420#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs