[ih] Internet Path Analysis Tool?

[Brian E Carpenter]

Jack,

I think you're looking for RIPE Atlas: https://labs.ripe.net/atlas

And there's a *lot* of stuff at http://www.caida.org/home/, of course.

Regards
   Brian Carpenter

On 2019-01-18 10:37, Jack Haverty 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:
> 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.
>>
> _______
> 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.
>