A Ping Too Far: Real World Network Latency Measurement

There is risk when doing experiments on real world systems and making real world measurements. In a theoretical system, a simulation, or a test bed, we can make assumptions about real world behaviors and gloss over potential problems. In a real world system, however, we have to solve those problems to get science done. Sometimes these are technical problems, like making sure a tool chain is consistent across many hosts. Sometimes these are policy problems, such as obtaining permission and access. The other users of a system have a reasonable expectation that their work will not be disrupted, so researchers studying those systems must be careful accommodate that expectation. Sometimes, systems researchers encounter these problems and a study must be changed or canceled, though the problem may have nothing to do with the study itself. Our goal was to make a high-quality all-to-all network latency map that captures features not present in existing latency data sets. We solved most of the technical problems needed to make the required measurements. We solved most policy problems too, often with complex technical solutions to get around a policy obstacle without creating disruptions. However, we eventually ran out of technical solutions: we ran afoul of a policy obstacle to a technical solution to a technical problem. There is no one to blame, and no one has done anything obviously wrong: the policy decision was a conservative one designed to protect the data of the regular users of the system. Although our resulting latency data set is not complete, we believe it still has value for various network applications. Our goal was to make a high-quality all-to-all network latency map that captures features not present in existing latency data sets. We solved most of the technical problems needed to make the required measurements. We solved most policy problems too, often with complex technical solutions to get around a policy obstacle without creating disruptions. However, we eventually ran out of technical solutions: we ran afoul of a policy obstacle to a technical solution to a technical problem. There is no one to blame, and no one has done anything obviously wrong: the policy decision was a conservative one designed to protect the data of the regular users of the system. Although our resulting latency data set is not complete, we believe it still has value for various network applications.