Transport Level Passive Ping Network Observer
Pollere believes the Internet community needs more passive diagnostic tools.
To that end,
we've been giving talks at the
IRTF MAPRG,
the
Stanford Networking Seminar
and
Google
to emphasize the fun and utility of extracting information
from real Internet traffic. In response to feedback at those
talks and to help
people new to passive network measurement get up to speed,
we coded and put out an open source example for others to
build on.
Measuring Round-Trip Delay in the Internet
Ping has been an essential tool for network engineers and
users from the beginning.
It computes the round-trip time to any host by sending it a packet
that requires a response and measuring the time until that
response is returned or "reflected" from the host.
This resemblance to active sonar gives ping its name.
Ping uses the lack of a response to determine reachability
and the measured reflection time to determine delay,
but only for the packets that it injects into a network.
Ping's key enabler, the ability to reflect a packet off a host,
was designed into IP's control message protocol, ICMP, for diagnostic
purposes.
Similar packet "reflections" exist in other parts of the Internet
protocol stack notably, TCP ACKs are a receiver's reflection of a
sender's data packet. The ACK stream allows senders to continuously
estimate a connection's round-trip time, critical for efficient loss
recovery.
This reflection mechanism only works for the sender and requires relatively complex
sequence number tracking. Another reflection mechanism was introduced
in RFC1323, a TCP "timestamp" option and this can be used by senders,
receivers and intermediaries to monitor connection behavior.
Passive Ping (pping)
When the timestamp option is used in a TCP connection,
it provides a naturally occurring reflected signal that
allows calculation of a "passive ping" (think of passive sonar)
that measures the round trip delay application packets experience
relative to any capture point on the connection's path.
Passive ping delays are collected per TCP connection with packets
of the connection's outbound (relative to the monitoring point) flow
providing the signal and
packets of the inbound flow the reflection.
The inbound flow IP source is the passively pinged host
and round trip times are reported relative to the packet capture point.
Unlike ping, pping measures the delay of two different round-trips from
the packets it monitors, i.e. the round-trip times to the applications at
both ends of a TCP connection. If pping is co-located with one of the
applications, it measures delay through the local protocol stack and the
application as well as the round-trip time to the communicating host.
If located along the path, e.g. at a WiFi router or a cable modem, delay
between the host endpoints can be bifurcated with respect to the location
of the packet capture.
Also unlike ping, pping captures all of the flows through it, giving
visibility to to the various Internet connections to the host.
Unlike some other passive metrics,
pping monitoring can start at any time in the lifetime of a connection,
i.e., it does not require SYN packets.
Our C++ code for a basic passive ping utility, pping, is
available.
It can be utilized as-is or as a basis for other monitoring utilities
and works on end hosts as well as on in-network elements.
pping can be configured to output to a mongo database and our
output line to websocket
nodejs program can be used to display in a client web page.
ppviz is a web-based visualizer we are
working on for pping and have made
available.
Any transport protocol with a suitable reflected signal can be used by pping,
In particular, RTP and other conferencing protocols could be used
but the necessary header information is usually encrypted.
Unencrypted protocols with reflected tags could be added to the libtins
library pping uses and that protocol could also be used by pping.
Further Information on Passive Monitoring at Pollere
Slides from a talk on passive monitoring that includes use of passive
ping deployed in a transparent bridge
can be found at Listening to Networks.
These include results from Pollere's
Transport Segment Delay Estimator (TSDE), developed under an
SBIR grant from the Department of Energy.
Video of a
Listening to Networks
talk at UCLA is also available.
Other talks on measurements using TSDE and on passive monitoring are available
on our Presentations page.
Passive Monitoring with a Transparent Bridge
For more information, contact info@pollere.net.
|