[ih] Internet Path Analysis Tool?

[Jack Haverty]

Thanks everyone.  I received several offline replies pointing me to Van
Jacobson's path analysis tool, and even a pointer to a downloadable more
recent (2005) reimplementation (Thanks to Mike Brescia!)  FYI, it's at:
http://www.kitchenlab.org/www/bmah/Software/pchar/

Unfortunately that tool doesn't seem to be very useful anymore since
it's based on pinging and many parts of the Internet seem to have
disabled the ability to be pinged.  I downloaded and ran the tool to
several sites just now and it reports 100% loss rate (nobody responds to
pings, at least in my neighborhood of the Internet).

I was really searching for a different tool, not based on pinging.  It
would require access to both ends of the path you're testing, e.g., the
ability to hang some kind of packet-capture device on a LAN at each end.
 That could be as simple as a Raspberry Pi running Etherape or similar
software, plugged in to the same LAN as your user machines so the Pi
could see the packets.

The packet capture would be carried out while you were using the
Internet in some fashion between points A and B.  It might be an
application using TCP/IP, like simple browsing, or an application using
IP with some kind of streaming protocol, or anything else that would
exchange IP packets.

The captured data would characterize how the Internet was behaving as
that real application was being used, and the data would be analyzed
"offline" (at least delayed a few seconds), with the timelines of the
two endpoints correlated.  Each end could see what it sent, and what it
received from the other end, and when.  In addition each end could see
any kind of control packets that it received from somewhere else - e.g.,
a Source Quench (assuming anybody actually sends those any more).

There could be many ways to display, extract statistics, and otherwise
view the captured data.  But one interesting way would be be show the
packets as blips on a timeline, much like an oscilloscope or datascope
display.

What I'm remembering is a display similar to what you see using audio
tools like Audacity, where you can see the actual waveform of audio,
zoom in and out, etc.

The difference is that the path tool could do things like color-code
dropped packets, duplicates, Source Quenches, as well as graph things
like current window size if it's a TCP packet stream.

By displaying the point A and point B timelines one above the other
(like a dual-trace scope), it could also highlight how packets were
delayed, reordered, or duplicated by drawing lines between the sender's
timeline and the receiver's.

Of course you could also load up the same test results but from
yesterday or last week or whatever, and compare with other test
sessions.   One use would be to take a dataset while everything was
considered "normal", to be used for comparison with a dataset taken when
"it's broken", to see what has changed.

I can "see" this tool in my head ... but I don't know if I'm remembering
something that I actually used, or just imagined years ago while trying
to debug Internet performance issues.  Perhaps I'm remembering some
vendor's in-house tool?  Or it might just be historical Internet
vaporware.....

Mike pointed me to some more recent IETF work, but so far I've found a
lot of proposals, frameworks, protocols, metrics, et al but no actual
implementations of anything, at least not publicly available.

/Jack


On 1/15/19 4:19 PM, Jack Haverty wrote:
> Memories fade...
> 
> I vaguely remember a discussion, decades ago, about a tool to analyze
> Internet behavior.  But I don't remember where, when, or even if it was
> a meeting or a conversation at a hotel bar, or whether anything happened
> afterwards.
> 
> The problem was how to qualitatively evaluate how a specific Internet
> path behaved.  The concept was to have a packet-trace tool (think
> something like Etherwatch) at each end, capturing all packets transiting
> between 2 endpoints (PCs probably), and filtering to extract only the
> packets associated with a particular "connection" (not necessarily TCP).
>  So you would capture two sets of data, one representing everything that
> got sent, and the other everything that got received.
> 
> There have been tools for a long time that do such captures.  The
> "analysis" part was to create a tool that took that capture data from
> the two ends, and correlated the two sets of data to analyze what
> happened to the packets along the way.  How many got dropped?  Delivered
> out of order?  How wide was the dispersion of delivery times?
> Duplicates?  How did behavior change with size, or rate of sending?
> Etc.  If a TCP connection was involved, how many packets were
> retransmitted?  How may were retransmitted needlessly because the "lost"
> packet arrived later?  Etc.
> 
> The goal was to develop a set of such metrics which would effectively
> measure the "quality" of a particular Internet path, track it over time,
> day-to-day, month, etc., and be able to set trigger points where that
> path would be considered "normal" or "degraded" or "unusable".
> 
> Did such a tool ever get implemented?  Best of course would be a link to
> a place to download it....one can dream.
> 
> Tnx,
> /Jack Haverty
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>