Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#6 Send a timestamp for every hash; use them for statistics

open
nobody
None
5
2008-08-19
2008-08-19
Peter Eckersley
No

We should send a timestamp along with every hash, so that we can calculate latency and jitter for all the traffic between Alice and Bob.

Currently the hashes sent in "sent" and "recd" messages are 4 bytes of hash fragment (as per the design document, more or less) and the 2 byte IP ID (which was used for debugging and never removed).

With care, the IP ID can probably be removed (though we should at least consider keeping it around with the opening_hash used to decide if a flow reported by Alice matches a flow reported by bob). That would get us back down from 6 to 4 bytes per packet. This can shrink further, at the cost of more hash collisions. Hash collisions aren't fatal at all, but they may end up breaking the forgery analysis code a bit, when there actually are forgeries.

Adding a timestamp will greatly increase the data per packet. Doing it naively would probably add an 8 byte double to every 4 byte hash! We'd do better with compression: Send the starting and ending timestamp for each batch (batch == contents of "sent" or "recd" message), sort the contents of the batch by time, and only encode the difference between each packet and where you'd expect it to be. Also, don't send more bits of timestamp precision than the clients' clocks can report.

There are easier or fancier ways to implement this timestamp compression. It doesn't have to be perfect, but it'd be great to shrink the timestamps down to 1-3 bytes / packet.

Discussion