[tor-bugs] #15482 [Tor]: Don't surprise users with new circuits in the middle of browsing

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Jul 25 10:28:34 UTC 2015


#15482: Don't surprise users with new circuits in the middle of browsing
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  mikeperry
  mikeperry              |     Status:  needs_information
         Type:           |  Milestone:  Tor: 0.2.7.x-final
  enhancement            |    Version:
     Priority:  normal   |   Keywords:  tbb-usability, MikePerry201503,
    Component:  Tor      |  tbb-wants, TorBrowserTeam201507R
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by yawning):

 Replying to [comment:27 mikeperry]:
 > As it is deployed today, I don't think that this patch should be
 changing the total number of circuits significantly. If you are
 continuously using a website, you will have *some* circuit open for it.
 Really the only thing this patch does is make you tend to use the same
 circuit for that activity rather than using a new one.
 >
 > In aggregate, I guess this *might* cause connections to live longer
 between relays, but I doubt it.

 Metrics needed here, a bit too late to really characterize the old
 behavior, but I believe that number of channels/circuits per relay metrics
 will be useful information to have.

 > What is more likely the culprit is that in Tor Browser 4.5, we also
 reset our connection keepalive to match to Firefox default of 2 minutes
 (up from 20 seconds), since we solved #4100. That would cause more
 connections to stay open, since the HTTP connections are now being kept
 open for longer. I think this in combination with more users is the real
 problem.
 >
 > SPDY and HTTP/2 will make this even worse, since its keep-alive duration
 is potentially infinite.

 I will reiterate that this isn't a fundamental problem with this patch,
 since relays SHOULD (MUST) be able to support talking to any other relay
 (and lots of clients or servers if they happen to be Guards/Exits).  You
 brought up testing inter-relay connectivity and delisting (or reducing the
 consensus weight) of relays that fail to build circuits.  I think this
 will be a good idea, moving forward but such tests are likely to be quite
 time consuming.  I seem to recall someone running this sort of experiment
 in the past, but I don't recall the trac number off the top of my head.
 I'd be willing to bet that due to internet quirks all relays can't talk to
 every other relay (even if they aren't stuck behind some crappy NAT box).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15482#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list