[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