Opened 5 years ago

Closed 4 years ago

Last modified 2 years ago

#13222 closed enhancement (duplicate)

Clients accessing a hidden service can establish their rend point in parallel to fetching the hsdesc

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorR

Description

Right now the client goes through the process of fetching the hidden service descriptor, and once it's there, then the client realizes it wants a rendezvous circuit ready. It could instead do these two steps in parallel.

Now, the reason not to do it is that we can just cannibalize an available general-purpose circuit and we've nearly got a rendezvous point. And then Tor client will indeed already try to keep general-purpose circuits around. So maybe it is not worth the wasted circuit? I'm not sure.

Child Tickets

Attachments (2)

rp-time-025.png (42.8 KB) - added by dgoulet 4 years ago.
ip-time-025.png (52.4 KB) - added by dgoulet 4 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 5 years ago by asn

Maybe at the time of fetching the descriptor we can even start establishing a 2-hop IP circuit ready to be extended when we learn the list of IPs?

But indeed we should consider how cannibalization influences this ooptimization.

Changed 4 years ago by dgoulet

Attachment: rp-time-025.png added

Changed 4 years ago by dgoulet

Attachment: ip-time-025.png added

comment:2 Changed 4 years ago by dgoulet

Just finished an experiment on chutney that is relevant to this ticket. If the network does not stop and a client request is done to the HS every 10 seconds requesting a new circuit (torsocks + user/pass), the rendez-vous point is 100% of the time cannibalized. See the graph attached "rp-time-025.png".

Few outliers that need investiguation creating two clusters (same behavior with IP btw) but apart from that, it's really fast vis-a-vis establishing IP where no cannibalization occurs. See graph attached "ip-time-025.png".

comment:3 Changed 4 years ago by sysrqb

Resolution: duplicate
Status: newclosed

dgoulet and i discussed this. We decided #13239 was a better way to handle this - which is basically preferring canabilization of an existing internal circuit over explicitly creating a rend circuit.

Marking this as a dupe of #13239, but reopen is there's better reasoning for preferring this ticket.

comment:4 Changed 4 years ago by arma

Sounds good. (Matt and David tell me that when we cannibalize a rendezvous circuit for the client side, we just use whatever three-hop internal circuit is lying around. So if we aim to have one lying around, and ready to cannibalize in-place whenever we need it, that should be good enough.)

Thanks!

comment:5 Changed 4 years ago by dgoulet

Keywords: SponsorR removed
Sponsor: SponsorR

comment:6 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:7 Changed 2 years ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.