[metrics-bugs] #30636 [Metrics/Analysis]: Something funky is going in Iran: numbers of relay users flies off to 1M+

[Tor Bug Tracker & Wiki]

#30636: Something funky is going in Iran: numbers of relay users flies off to 1M+
------------------------------+------------------------------
 Reporter:  cypherpunks       |          Owner:  metrics-team
     Type:  task              |         Status:  new
 Priority:  Medium            |      Milestone:
Component:  Metrics/Analysis  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  ir                |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------

Comment (by arma):

 Two more data points here:

 (A) I am coming to believe that our user count numbers are based on
 counting requests, not on counting successful deliveries of the consensus.
 So if a client gets far enough through the process to request a
 connection, but then has their connection cut, (1) we will count them as a
 user, and (2) they will come back somewhere else soon after to retry, and
 we'll count that next one as a new user. I am beginning to suspect that a
 factor in what's happening here. But that still doesn't explain why the
 number keeps going up -- it's not like clients start asking more and more
 frequently as they fail more often.

 (B) We do have a count of successful consensus deliveries, vs delivery
 attempts that time out. Dir mirrors can't tell whether the client receives
 all the bytes, but because the consensus takes more than one stream window
 worth of cells to deliver, the dir mirrors can tell that all but the last
 stream window (250KB) of cells were acknowledged by the client. *But*,
 with the advent of consensus diffs, the entire diff fits within a single
 stream window, so every time a client asks for a diff, we're going to
 count that delivery as a success, even if no bytes actually make it to the
 client.

 (B') And while we're on that topic, there actually *is* a way to learn
 whether the client received the last part -- see the concern in
 https://trac.torproject.org/projects/tor/ticket/30926#comment:3 where we
 get a stream-level sendme for an unknown streamid. That happens when we've
 finished sending all of the consensus bytes, and then we send the end
 cell, and then we close the stream on our side, and we get a sendme with
 an unknown streamid because we've already forgotten about the stream. But
 all of the data is there for us to be able to confirm that the client has
 received (nearly all of) the bytes, if we want to.

 We should probably make a bunch of tickets out of these various bugs and
 feature ideas, but I wanted to get them written up somewhere first.

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