REVIEW: "Sting: a TCP-based Network Measurement Tool"
SUMMARY
The paper proposes the use of TCP for network measurement with high
accuracy. In particular, it proposes sting, a tool which measures packet
loss rate between a source host and some target. The paper observes that
existing measurement tools are inadequate: ICMP based ping and traceroute
are unable to distinguish between forward and reverse direction losses.
Loss asymetry is important because in TCP, for example, ACK losses are
less problematic than data losses. ICMP tools require universal ICMP echo
or ICMP time exceeded services deployment. Operating Systems limit ICMP,
Solaris for example, limits ICMP response rate, inflating packet loss
reported. Networks filter ICMP, firewals respond on behalf of hosts
preventing real end-to-end measurement. Clearly ICMP usefulness as
measurement tool is reducing. Newer approaches require cooperating
infrastructure not widely available.
Sting operates in the premise that the target must run a TCP based
service, such as a web server, which will act as an involuntary
infrastructure. The tool operates in two phases data seeding and hole
filling. During data seeding it sends data to target, and in hole filling
it determines what packes were lost in each direction.
KEY STRENGTHS
Sting is able to distinguish losses in the forward direction from those in
the reverse. It requires no explicit cooperation from the target host. It
is able use TCP even though the protocol allows for delayed ACKs, by
skiping first sequence number during the data seeding phase, send it in
hole filling. It is also able to measure packet bursts even when given
small buffer size at targets, by overlaping large packets so only one byte
of each is buffered.
Sting is also able to handle servers that terminate connections
unexpectedly (sending an abortive reset or RST messages) by sedning legal
HTTP requests with receiver window of 0. The server will thus not close
connection until it can send this trapped response.
Experimental results show that sting is stable, produces results
compatible with those of ping, and reports correct results when packes are
synthetically droped.
Interesting results have also been found using sting, such as the fact
that forward loss rates are independent from reverse ones, although both
icrease during peak hours. In fact the average reverse loss rate (1.5%)
was found to be generally higher than the forward loss rate (0.7%).
WEAKNESSES
To handle ill behaved servers, sting sends HTTP requests with a receiver
window of zero, as discussed above, however no discussion is provided to
address what overhead such approach causes on the server. Could this make
service providers want o deny requests with zero receiver windows?
Although efforts have been made to measure effects of packet bursts in
forward direction, sting has no ability to do so for packets in the
reverse direction.
A completely user level implementation of such TCP based measuring tool
not may be possible. For sting, the authors had to modify one line of
kernel code.
Sting can only be used to measure losses to servers and not to client end
hosts. Moreover, the current implementation is HTTP specific thus will not
work with other types of servers.
Received on Mon Oct 31 2005 - 10:42:09 EST
This archive was generated by hypermail 2.2.0 : Mon Oct 31 2005 - 10:45:50 EST