Feature request: Use reported to train/attack instead of userspace_rtt

[andresriancho]

Feature request: Use reported to train/attack instead of userspace_rtt. In some cases the reported field is more accurate. I'm working on a case where the remote web server adds a X-Runtime header in the response with the time it took to resolve the HTTP request, which doesn't have "internet jitter"; and I would love to use that for all the process instead of the userspace_rtt

I can do that by hacking the sampler, but maybe it should be documented/supported, etc.

[ecbftw]

Yes, this is an outstanding feature that is needed. The current state of things is this: the reported field is properly recorded in the database, along with the packet timing information. When the test and training bootstraps are run, the low-level database queries also retrieve this information and make it available in a normalized way to the caller. However, that's where support for reported times stops right now. (Note that userspace_rtt is not used; only the packet_rtt field is currently used, which is derived from direct packet analysis. The userspace_rtt data is normally pretty awful in quality.) Here is what is needed to finish this:

1. Update all training and test algorithms (in lib/nanownlib/train.py) to allow the caller to specify which RTT measurements are used.
2. Update packet analysis procedures to detect whether the reported times collected are sane and are "better" than the packet RTTs. The best data set would then be stored in the DB for later steps, though could be overridden by the user.
3. Update the bin/train script to leverage the data set identified during packet analysis and pass the appropriate parameter down to the training algorithms.

In the short term, if you have a specific app you are testing and you want to use the reported data, you could hack the libraries by making the following changes:

• Replace all "unusual_packet" with "unusual_reported"
• Replace all "other_packet" with "other_reported"

Be sure to apply this everywhere in the code. It's ugly, yes, but if you're on a short time line it is your best option for now. The good thing is, if you already collected a bunch of reported times, you can still use that data and simply re-run the train/test processes.