[tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."

[Tor Bug Tracker & Wiki]

#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
 Reporter:  arma                         |          Owner:                    
     Type:  enhancement                  |         Status:  needs_revision    
 Priority:  normal                       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                          |        Version:                    
 Keywords:  tor-client, MikePerry201212  |         Parent:  #5456             
   Points:                               |   Actualpoints:  19                
-----------------------------------------+----------------------------------

Comment(by nickm):

 Replying to [comment:22 mikeperry]:
 > Replying to [comment:18 nickm]:
 > > Okay, part two (which covers the rest of the branch up to
 ccaeef22e168af34e9b6a63d65ce17e58dd702e2) is much shorter:
 > >
 > > Setting timestamp_dirty in circuit_extend_to_new_exit seems wrong.
 > > The circuit *isn't* dirty!  Maybe overloading timestamp_dirty in this
 > > way, rather than grabbing a new bit, is a mistake?
 >
 > Hrmm. Both codepaths that cause circuit_extend_to_new_exit to fire seem
 to indicate it's dirty to me: We're either re-extending an intro circ, or
 cannibalizing an existing circuit to send it to a specific new exit. In
 neither of these cases do we really want to re-use this circuit for some
 random new traffic, right?

 That's an abstraction abuse.  Just because in every case where we
 currently cannibalize a circuit, we want to mark it dirty, that doesn't
 mean that cannibalizing a circuit should mark it dirty, right?

 > You'll note that I also added a dirty timestamp in
 rend_service_rendezvous_has_opened() for similar reasons..

 But that one really is a dirtying thing: it means that the circuit has
 been used.

 > However, if this bit causes the code that did the re-extending/opening
 to suddenly decide "Eww, a dirty circuit. Better make a fresh one!" once
 the extend completes, that could be bad. It didn't *seem* to do this, but
 some of those cannibalization corner cases are certainly screwy...
 >
 > > 04866055e8dadc9eb5b09773 freaks me out.  This feels like a significant
 > > redesign of the whole concept, and I didn't see it mentioned on
 > > tor-dev anywhere or on the tickets.  "As long as end-to-end tagging is
 > > possible, we assume the adversary will use it over hop-to-hop
 > > failure"?  Is there any discussion of this anyplace?  (The idea here
 > > seems to be that entry nodes are allowed to filter for the second hop
 > > as much as they like, and the pathbias code won't care, but that if
 > > they start tagging/filtering for the third hop or later, they need to
 > > be called out. Is that right?)
 >
 > Yes, this is the idea, but there has been no discussion yet. I added it
 after watching the end-to-end circuit success rate repeatedly fluctuate
 between 90% and 50%, due almost entirely to per-hop onionskin failure (CPU
 overload).
  [...]

 What you say is plausible, but it really needs to go on tor-dev or in the
 proposal or somewhere so we have a record of our design and rationale.  We
 need to get better at making sure that development discussion of this kind
 goes on in tor-dev, or at least gets copied there once there's a
 consensus.

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