Provide timestamps in the CIRC_BW and STREAM_BW events

Tor emits stream and circuit bandwidth events about once per second. However delays in the control port and controller libraries makes the event time not reliable enough for accurate bandwidth measurements.

It would be useful for making bandwidth authorities if both the STREAM_BW and CIRC_BW events included timestamps in the event.

changed milestone to %Tor: 0.3.2.x-final

added component::core tor/tor milestone::Tor: 0.3.2.x-final needs-decision owner::donncha points::0.1 priority::medium resolution::implemented review-group-20 reviewer::dgoulet severity::normal status::closed tor-control tor-spec type::enhancement labels

I've pushed commits for Tor and the spec to my Github forks at:

https://github.com/DonnchaC/tor/compare/master...ticket19254 https://github.com/DonnchaC/torspec/compare/master...feature19254

Trac:
Status: new to needs_review

Trac:
Keywords: N/A deleted, 029-proposed added

I wonder if it might make sense to add a flag that made all events get timestamps. Or would that be useless overgeneralization? Also I wonder if a fraction-of-seconds field would be helpful.

I don't think it would be so straightforward to add timestamps to all the events. Some events are using keyword fields, and others use positional fields.

By fraction-of-seconds field to you mean having the microseconds from the timestamp listed in a separate field? Would that be much more helpful than just parsing the timestamp in the controller library you are using?

I have added event 1ms precision timestamps on a TCP control port client. Cross-checking against circuit events that include a TIME_CREATED field gives a perfect match.

So it seems the control protocol has low latency and clients already have the option of getting sufficiently accurate timestamps.

cypherpunks: Thanks for checking that out. So a client with low load can get events quickly.

However I'm working on some asynchronous programming using Python Twisted. I think there are less guarantees of the program immediately getting and processing the event when it is emitted when using asynchronous style.

Trac:
Milestone: N/A to Tor: 0.2.???

Trac:
Keywords: N/A deleted, 029-nickm-says-no added

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: 029-nickm-says-no deleted, N/A added

Trac:
Keywords: 029-proposed deleted, needs-spec tor-control needs-decision added
Milestone: Tor: unspecified to Tor: 0.3.2.x-final

Creating review-group-20

Trac:
Keywords: needs-spec tor-control needs-decision deleted, tor-control, needs-spec, review-group-20, needs-decision added

setting owner

Trac:
Status: needs_review to assigned
Owner: N/A to donncha

Trac:
Status: assigned to needs_review

lgtm;

I've taken the tor patch to make it work on 032 (no change was needed): ticket19254_032_01

Spec patch needed a small change to say 032 and not 029: ticket19254_01

Trac:
Reviewer: N/A to dgoulet
Status: needs_review to merge_ready
Points: N/A to 0.1

Trac:
Cc: N/A to atagar

Trac:
Keywords: needs-spec deleted, tor-spec added

Spec change looks good to me - thanks!

merged!

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 48m

moved to tpo/core/tor#19254 (closed)