Sting: a TCP-based Network Measurement Tool Review

Sting: a TCP-based Network Measurement Tool Review
Review By: Troy Ronda

The Internet was not designed for measuring performance. It is critical
to measure the behavior between hosts to diagnose current problems and
to design future services. Due to these problems, tools must use the
limited built-in services or deploy substantial amounts of
infrastructure. The packet-loss rate affects bandwidth delivered by TCP
proportional to 1/sqrt(lossrate). ICMP tools such as ping and traceroute
can measure packet-loss rate. They cannot measure loss asymmetry and
ICMP filtering has also reduced their usefulness. Loss asymmetry is
important since loss of acknowledgments in TCP is less important than
loss of data packets. This paper describes STING, a tool that does not
require any infrastructure and whose packets are not filtered by
firewalls. This tools exploits properties in TCP to implicitly record
loss rates in both the forward and reverse directions. TCP sends
acknowledgments for in-sequence packets receipts. If we create a hole in
the sequence numbers at the first position, most TCP implementations
will send an acknowledgment for each packet (since packets are not
sequenced). Now if we send a number of packets to a target host, we will
receive a number of acknowledgments back. Once we send the first
sequence number to the target, we will receive an acknowledgment
specifying the first “hole” or one that specifies that no packets were
lost. These “holes” correspond to lost packets sent to the target. We
send the target missing packets until all packets have been received
(i.e. holes closed) and record the loss rate. Formulas are given for
determining loss rates based on this information.

Very well written paper! This tool is very nice. Papers, such as STING,
that do not require infrastructure or modifications but still present
viable methods are most enjoyable. I had to think about why the formula
holds in the reverse direction for awhile but it seems to be correct. It
is surprising that no one had previously considered using an implicit
property of TCP to record this information. I am also intrigued by the
testing strategy employed in the paper. (i.e. Pick the top 50 hosts and
randomly pick other hosts). Perhaps this strategy can be used for
testing the location project in class. I liked the comparison and
explanations of the loss rate difference between top hosts and random
hosts. It was also good to see that the authors refused to implement
methods to remotely bypass congestion control as they are concerned
about security risks (and the tool would probably have broken when
sys-admins closed this security hole anyways).

The authors had to change a single line of kernel code. This is a
concern for the paper as one wonders how many operating systems have the
same “problem” (eg. Windows). The suggestions given, such as using
built-in firewall rules seems to be a good one. It will be interesting
to see if the authors managed to build a fully-portable tool. The other
down-side is that the tool must assume that all TCP implementations are
correct. This problem is shown in the paper with laser printers and NAT
boxes. If TCP changes in the future then the tool will have to be
modified – though I do not consider this a big problem.
Received on Mon Oct 31 2005 - 10:45:50 EST