[ih] Internet Path Analysis Tool?
jhlowry at mac.com
Fri Jan 18 05:06:06 PST 2019
You might look at what RIPE Atlas is doing.
> On Jan 17, 2019, at 4:37 PM, Jack Haverty <jack at 3kitty.org> wrote:
> 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:
> 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
> 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
> 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.
>> 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
>> 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.
>> /Jack Haverty
>> internet-history mailing list
>> internet-history at postel.org
>> Contact list-owner at postel.org for assistance.
> internet-history mailing list
> internet-history at postel.org
> Contact list-owner at postel.org for assistance.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Internet-history