Opened 5 years ago

Last modified 2 months ago

#13194 new enhancement

Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell

Reported by: arma Owned by:
Priority: Very Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, tor-hs, needs-design privcount-maybe metrics performance
Cc: neel Actual Points:
Parent ID: Points:
Reviewer: dgoulet Sponsor: Sponsor27-can

Description

In messing with #13193, I ended up with lines like

Sep 19 02:12:42.656 [info] stats_label_circ(): circ has newly been used for hs: ESTABLISH_RENDEZVOUS
Sep 19 02:12:55.131 [info] stats_label_circ(): circ has newly been used for hs: RENDEZVOUS1

and

Sep 19 02:05:53.253 [info] stats_label_circ(): circ has newly been used for hs: ESTABLISH_RENDEZVOUS
Sep 19 02:05:54.033 [info] stats_label_circ(): circ has newly been used for hs: RENDEZVOUS1

That second one looks pretty good speed-wise, and that first one looks pretty ugly. I assume some of this slow-down is due to #13151, but I don't know how much.

Wouldn't it be cool to track this delay value over time, to see if things are getting better or worse, to be able to measure how big a deal things like #13151 are, etc?

Child Tickets

Change History (17)

comment:1 Changed 4 years ago by nickm

Keywords: SponsorR removed
Sponsor: SponsorR

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

comment:2 Changed 4 years ago by dgoulet

Sponsor: SponsorRSponsorR-can

Move those from SponsorR to SponsorR-can.

comment:3 Changed 3 years ago by teor

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

Milestone renamed

comment:4 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:5 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:6 Changed 2 years ago by dgoulet

Keywords: tor-hs added
Priority: MediumVery Low
Severity: Normal
Sponsor: SponsorR-can

This sounds good to have once we have privacy preserving statistics.

comment:7 Changed 2 years ago by nickm

Keywords: needs-design privcount-maybe metrics performance added

comment:8 Changed 2 years ago by teor

Tracking the related PrivCount work here:
Rend: https://github.com/privcount/privcount/issues/344

comment:9 Changed 2 years ago by nickm

Sponsor: SponsorQ-can

comment:10 Changed 5 months ago by arma

I continue to think this would be a cool and useful metric to track. Especially in the modern world where many clients, including attacking clients, generate a rendezvous point and then, due to congestion at the onion service, it takes a really really long time before a rendezvous attempt is made. It would be great to know how pervasive this problem is, and how it is changing over time. I also don't think privcount level noise is required for it (but I wouldn't object to having it).

comment:11 Changed 4 months ago by neel

Cc: neel added
Owner: set to neel
Status: newassigned

comment:12 Changed 3 months ago by neel

Status: assignedneeds_review

The PR is here: https://github.com/torproject/tor/pull/1175

I don't know if it is for v2 only or it also includes v3. I am assuming the latter.

comment:13 Changed 3 months ago by teor

Milestone: Tor: unspecifiedTor: 0.4.2.x-final

I think this patch is useful, but I have some questions for arma and the reviewer:

  1. Is this code on the fast path? Do the extra struct members take up too much RAM?
  2. How can we track this value over time? Shiuld we add it to onionperf?
  3. Can we implement a similar stat on relays instead? And publish some values in the extra info stats?
Last edited 2 months ago by teor (previous) (diff)

comment:14 Changed 3 months ago by dgoulet

Reviewer: dgoulet

comment:15 Changed 3 months ago by dgoulet

Milestone: Tor: 0.4.2.x-finalTor: unspecified
Sponsor: SponsorQ-canSponsor27-can
Status: needs_reviewnew

Yeah I will echo teor's questions here and add more.

I think it is very useful to have this timing but we should get this value into a more broad framework that does timing measurements _only_ if enabled (torrc or configure or ...).

Then get that data out differently then log_info()... Parsing logs for this kind of measurements is really not where we should go.

It is totally possible that this kind of work (timing measurements) falls under s27 work as we are about to start working on this big piece: #30200

I'm deferring this until we get a clearer picture of where we want to go with these type of measurements. But for now, I'm not very keen on merging this approach with log_info().

comment:16 Changed 2 months ago by neel

Owner: neel deleted
Status: newassigned

Removing myself from assigned.

comment:17 Changed 2 months ago by neel

Status: assignednew
Note: See TracTickets for help on using tickets.