TCP-Based RTT Calculation

[phillip-stephens]

While we do have the icmp_echo_time module, it could be useful to add a ping to TCP as well as an optional output field.

With the seq_no field we have 32 bits, so I'm thinking we can store 1/10 ms. precision timestamps in the seq_no as long as scans don't take longer than (2^32) / (10^4) / 60 / 60 = 119 hours.

Then on probe response reception, we can calculate the observed latency using the ack_num

New Output field name: latency: time difference between when probe response was received and probe was sent, to 1/10 ms. precision

[phillip-stephens]

Had someone at IMC ask if we supported this with TCP module, should be an easy addition.

Will need to handle the case where our time wraps around back to zero, where the response probe's time is less than the probe's.

[paraacha]

Came here to put a request for this based on our IMC discussion, thanks Phillip :) would be neat to get RTT measurements while scanning as usual (I think they may also be more reliable than ICMP ones).

[zakird]

@paraacha any chance that you want to take a first stab on this? Our attention is a bit captured on other aspects of the zmap toolkit over the next few months.

[droe]

I have an implementation of exactly this lying around, slightly different precision tradeoff with more validation bits, less timestamp bits, but more importantly it's a compile-time switch instead of a runtime switch to enable, so needs some reworking to be able to merge into ZMap proper. Happy to rebase on latest main and share the branch if there's interest.

[zakird]

@droe that'd be great if you're willing. thank you! Makes sense to me re validation.

[droe]

So here's my old branch rebased on latest main: https://github.com/droe/zmap/tree/droe/rtt

If someone wants to take it from there, feel free, otherwise I'll eventually do the needed refactoring.

Options I see for activating it:

• Global option (--rtt) that probe modules can chose to support or not support? Arguably the cleanest solution, downside is more up-front work and complexity.
• TCP SYN scan probe argument (--probe-args=rtt)? Limits complexity to the one probe module, less work to implement, but also more work to later extend to other probe modules.
• Separate scan mode (--probe-module=tcp_synrttscan or some such)? Probably too much code duplication, just listing for completeness.

Also, unsure if it'd be worth making the precision vs validation tradeoff configurable (at runtime, or at compile-time).

[diwu-sf]

@droe thanks for that draft implementation.

I'm trying to understand a few pieces of the:

• in timespec_to_ms64 it looks like the precision is only at the millisecond level, would much prefer to track at 1/10th of a millisecond precision
• can we use 28bit counter, and only 4 bit for the validation, this should give a wrap around time of 7.5 hours