Re: [tor-bugs] #30798 [Metrics/Onionperf]: Develop and deploy tgen model resembling ping

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#30798: Develop and deploy tgen model resembling ping
-------------------------------+------------------------------
 Reporter:  karsten            |          Owner:  metrics-team
     Type:  enhancement        |         Status:  new
 Priority:  High               |      Milestone:
Component:  Metrics/Onionperf  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:
-------------------------------+------------------------------

Comment (by irl):

 This model would be looking at modeling something close to ICMP ping, but
 it's quite an approximation. In Internet Engineering, where you're dealing
 with packet switched networks, ping can be useful to determine both round
 trip times (average, min, max, jitter) and packet loss. In our case we are
 dealing with virtual circuits overlaid onto a packet switched network.
 This means that we're only going to get round trip times, as if there is
 packet loss we will just see the circuit go down and won't be able to
 probe further.

 We can still do all the round trip time metrics:

 * average - how long does it typically take to get a reply?
 * min - upper bound for latency when network is unloaded
 * max - lower bound for latency when network is loaded
 * max minus min - lower bound for maximum load induced queuing delay
 * jitter - variation in latency

 The second probe does depend on the first probe in a way that is not the
 case for ICMP. Being part of the same stream means that various counters
 and timers are going to be linked between probes. We should explicitly
 acknowledge this, work out what those counters/timers are (somewhere in
 the rate limiting code) and decide if we are affected by them or not.

 If there is something like Nagle's algorithm going on then we should
 ensure that we're getting all the right flushes in and that we're not
 ending up batching our requests.

 From discussion with Ana this should be relatively easy to implement the
 model, and all the data would be captured in the tgen log for analysis.
 I'm not sure if it is easier to hack something together, or to use the
 existing framework, which could be flexible enough to be modified simply.

 If we're getting numbers that look reasonable then this is probably enough
 for the upcoming meeting but I'd want to make sure we're not confusing
 what these numbers mean. This work may also be useful for scaling in
 general to better understand what counters/timers exist. Maybe we can work
 with a network team person to understand this.

 In the future it may also be interesting to port
 [https://www.bufferbloat.net/projects/codel/wiki/RRUL_test_suite/ RRUL] to
 a tgen model. That's not a cheap test to run though.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs