Review of Sting

This paper presents a TCP based tool to measure packet loss rate. It can
distinguish the loss rate of the forward and reverse path. Sting's
advantage is no change on the target side since it behaves like a
user-level TCP on the probing side, implemented by raw sockets and packet
filters.

However, the dependence on TCP leads to the weakness of sting. It could be
seriously influenced by the variants of TCP implementation and future
modification. In particularly, it is not suitable for measuring losses
over shorter time scales since TCP ACK is designed to be accumulative.
Although out of sequence could solve this problem in some degree, if SACK
or other ACK mechanisms is used, sting may not work well. Moreover, the
measurement could be inaccurate. Some retransmitted packets may not be
really lost; it could be delayed for a while due to different routing
paths and finally reach the TCP receiver. But sting considers them as lost
packets.

Also, sting cannot flexibly measure the loss rates of big packets on the
reverse path. TCP ACK could be very small or delayed for subsequent
packets. And it is impossible to set the interval between different ACK
packets. So, if we want to more accurately measure the loss rate on both
forward and reverse path, the measurement software should run on both
sides. This is reasonable since the applications, such as network games,
are usually installed on both client and server sides.

In brief, the accuracy and flexibility of sting cannot meet the normal
requirements due to its dependence on TCP.
Received on Mon Oct 31 2005 - 03:58:38 EST