<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">You might look at what RIPE Atlas is doing.</div><div dir="ltr"><a href="https://atlas.ripe.net/landing/about/">https://atlas.ripe.net/landing/about/</a></div><div dir="ltr"><br></div><div dir="ltr">John</div><div dir="ltr"><br>On Jan 17, 2019, at 4:37 PM, Jack Haverty <<a href="mailto:jack@3kitty.org">jack@3kitty.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>Thanks everyone. I received several offline replies pointing me to Van</span><br><span>Jacobson's path analysis tool, and even a pointer to a downloadable more</span><br><span>recent (2005) reimplementation (Thanks to Mike Brescia!) FYI, it's at:</span><br><span><a href="http://www.kitchenlab.org/www/bmah/Software/pchar/">http://www.kitchenlab.org/www/bmah/Software/pchar/</a></span><br><span></span><br><span>Unfortunately that tool doesn't seem to be very useful anymore since</span><br><span>it's based on pinging and many parts of the Internet seem to have</span><br><span>disabled the ability to be pinged. I downloaded and ran the tool to</span><br><span>several sites just now and it reports 100% loss rate (nobody responds to</span><br><span>pings, at least in my neighborhood of the Internet).</span><br><span></span><br><span>I was really searching for a different tool, not based on pinging. It</span><br><span>would require access to both ends of the path you're testing, e.g., the</span><br><span>ability to hang some kind of packet-capture device on a LAN at each end.</span><br><span> That could be as simple as a Raspberry Pi running Etherape or similar</span><br><span>software, plugged in to the same LAN as your user machines so the Pi</span><br><span>could see the packets.</span><br><span></span><br><span>The packet capture would be carried out while you were using the</span><br><span>Internet in some fashion between points A and B. It might be an</span><br><span>application using TCP/IP, like simple browsing, or an application using</span><br><span>IP with some kind of streaming protocol, or anything else that would</span><br><span>exchange IP packets.</span><br><span></span><br><span>The captured data would characterize how the Internet was behaving as</span><br><span>that real application was being used, and the data would be analyzed</span><br><span>"offline" (at least delayed a few seconds), with the timelines of the</span><br><span>two endpoints correlated. Each end could see what it sent, and what it</span><br><span>received from the other end, and when. In addition each end could see</span><br><span>any kind of control packets that it received from somewhere else - e.g.,</span><br><span>a Source Quench (assuming anybody actually sends those any more).</span><br><span></span><br><span>There could be many ways to display, extract statistics, and otherwise</span><br><span>view the captured data. But one interesting way would be be show the</span><br><span>packets as blips on a timeline, much like an oscilloscope or datascope</span><br><span>display.</span><br><span></span><br><span>What I'm remembering is a display similar to what you see using audio</span><br><span>tools like Audacity, where you can see the actual waveform of audio,</span><br><span>zoom in and out, etc.</span><br><span></span><br><span>The difference is that the path tool could do things like color-code</span><br><span>dropped packets, duplicates, Source Quenches, as well as graph things</span><br><span>like current window size if it's a TCP packet stream.</span><br><span></span><br><span>By displaying the point A and point B timelines one above the other</span><br><span>(like a dual-trace scope), it could also highlight how packets were</span><br><span>delayed, reordered, or duplicated by drawing lines between the sender's</span><br><span>timeline and the receiver's.</span><br><span></span><br><span>Of course you could also load up the same test results but from</span><br><span>yesterday or last week or whatever, and compare with other test</span><br><span>sessions. One use would be to take a dataset while everything was</span><br><span>considered "normal", to be used for comparison with a dataset taken when</span><br><span>"it's broken", to see what has changed.</span><br><span></span><br><span>I can "see" this tool in my head ... but I don't know if I'm remembering</span><br><span>something that I actually used, or just imagined years ago while trying</span><br><span>to debug Internet performance issues. Perhaps I'm remembering some</span><br><span>vendor's in-house tool? Or it might just be historical Internet</span><br><span>vaporware.....</span><br><span></span><br><span>Mike pointed me to some more recent IETF work, but so far I've found a</span><br><span>lot of proposals, frameworks, protocols, metrics, et al but no actual</span><br><span>implementations of anything, at least not publicly available.</span><br><span></span><br><span>/Jack</span><br><span></span><br><span></span><br><span>On 1/15/19 4:19 PM, Jack Haverty wrote:</span><br><blockquote type="cite"><span>Memories fade...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I vaguely remember a discussion, decades ago, about a tool to analyze</span><br></blockquote><blockquote type="cite"><span>Internet behavior. But I don't remember where, when, or even if it was</span><br></blockquote><blockquote type="cite"><span>a meeting or a conversation at a hotel bar, or whether anything happened</span><br></blockquote><blockquote type="cite"><span>afterwards.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The problem was how to qualitatively evaluate how a specific Internet</span><br></blockquote><blockquote type="cite"><span>path behaved. The concept was to have a packet-trace tool (think</span><br></blockquote><blockquote type="cite"><span>something like Etherwatch) at each end, capturing all packets transiting</span><br></blockquote><blockquote type="cite"><span>between 2 endpoints (PCs probably), and filtering to extract only the</span><br></blockquote><blockquote type="cite"><span>packets associated with a particular "connection" (not necessarily TCP).</span><br></blockquote><blockquote type="cite"><span> So you would capture two sets of data, one representing everything that</span><br></blockquote><blockquote type="cite"><span>got sent, and the other everything that got received.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>There have been tools for a long time that do such captures. The</span><br></blockquote><blockquote type="cite"><span>"analysis" part was to create a tool that took that capture data from</span><br></blockquote><blockquote type="cite"><span>the two ends, and correlated the two sets of data to analyze what</span><br></blockquote><blockquote type="cite"><span>happened to the packets along the way. How many got dropped? Delivered</span><br></blockquote><blockquote type="cite"><span>out of order? How wide was the dispersion of delivery times?</span><br></blockquote><blockquote type="cite"><span>Duplicates? How did behavior change with size, or rate of sending?</span><br></blockquote><blockquote type="cite"><span>Etc. If a TCP connection was involved, how many packets were</span><br></blockquote><blockquote type="cite"><span>retransmitted? How may were retransmitted needlessly because the "lost"</span><br></blockquote><blockquote type="cite"><span>packet arrived later? Etc.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The goal was to develop a set of such metrics which would effectively</span><br></blockquote><blockquote type="cite"><span>measure the "quality" of a particular Internet path, track it over time,</span><br></blockquote><blockquote type="cite"><span>day-to-day, month, etc., and be able to set trigger points where that</span><br></blockquote><blockquote type="cite"><span>path would be considered "normal" or "degraded" or "unusable".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Did such a tool ever get implemented? Best of course would be a link to</span><br></blockquote><blockquote type="cite"><span>a place to download it....one can dream.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Tnx,</span><br></blockquote><blockquote type="cite"><span>/Jack Haverty</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______</span><br></blockquote><blockquote type="cite"><span>internet-history mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:internet-history@postel.org">internet-history@postel.org</a></span><br></blockquote><blockquote type="cite"><span><a href="http://mailman.postel.org/mailman/listinfo/internet-history">http://mailman.postel.org/mailman/listinfo/internet-history</a></span><br></blockquote><blockquote type="cite"><span>Contact <a href="mailto:list-owner@postel.org">list-owner@postel.org</a> for assistance.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>_______</span><br><span>internet-history mailing list</span><br><span><a href="mailto:internet-history@postel.org">internet-history@postel.org</a></span><br><span><a href="http://mailman.postel.org/mailman/listinfo/internet-history">http://mailman.postel.org/mailman/listinfo/internet-history</a></span><br><span>Contact <a href="mailto:list-owner@postel.org">list-owner@postel.org</a> for assistance.</span><br></div></blockquote></body></html>