There are at least two different ways to define RPM, both of which might be relevant.
At the TCP layer: it can be directly computed from a packet capture. The trick is to time reverse a trace and compute the critical path backwards through the trace: what event triggered each segment or ACK, and count round trips. This would be super robust but does not include the queueing required in the kernel socket buffers. I need to think some more about computing TCP RPM from tcp_info or other kernel instrumentation - it might be possible.
A different RPM can be done in the application, above TCP, for example by ping-ponging messages. This would include the delays traversing the kernel socket buffers which have to be at least as large as a full network RTT.
This is perhaps an important point: due to the retransmit and reassuebly queues (which are required to implement robust data delivery) TCP must be able hold at least a full RTT of data in it's own buffers, which means that under some conditions the RTT as seen by the application has be be at least twice the network's RTT, including any bloat in the network.
Thanks,
--MM--
The best way to predict the future is to create it. - Alan Kay
We must not tolerate intolerance;
however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of control;
too weak risks being mistaken for tacit approval.