I'm still not sure how to talk about weialgo and the knowledge I'm trying to convey.
The mechanics of packet communications over a global network using interactive applications over TCP is not a simple one. Honestly, it's deceptively complex.
My other hobby is airplanes and aircraft homebuilding. I don't do as much anymore since I lost my medical, but I still help others from time to time in the building of their airplanes, and I've been building a two seat single engine with someone else since 2005.
Building an experimental aircraft is far easier than trying to get a global network to the point of being able to support interactive apps from a single point. Also, in an experimental aircraft, the person you affect when you buckle yourself in and start the engine up is you (if you do have any passengers, I'm pretty sure the big "EXPERIMENTAL AIRCRAFT" notice on the plane let's them know what they're getting into). With IT Systems (particularly packet networks), you affect everyone who uses or connects through the system you build and support.
Building an airplane, easy (it's alot of work, but it's easy to do work, easy to understand work, volume does not make hard). Understanding everything about packet networks and how to make interactive applications work over them at distance, hard. That's about good as I can say it without writing books.
There's a snippet I wrote for a draft post that I think tries to take this on from a different angle:
-------------------------------------------------------------------------------------------
Most of this conversation hinges on the work of John Nagle. Most network engineers know Mr. Nagle through his work on his namesake Nagle Algorithm (which makes me think, with the change of focus of weialgo, maybe it'd be more fitting to rename it Nagalgo... Problem is, he already has an algorithm named after him). But, what he really should be famous for is inventing the foundational queuing discipline, fair queuing. Wikipedia and RFC 970. On top of this, he was instrumental at designing and documenting the initial phases of TCP Congestion Control (RFC 896), which was fundamental to making the early (80's) Internet to work.
Honestly, if kids need to learn about Charles Babbage as part of high school computer classes, I feel that the concepts of John Nagle should be taught as part of any serious college or higher level curriculum which covers the Internet and what makes it work. I don't know Mr. Nagle, but, he is the first person to document the essential processes and put into practice the concepts that make the Internet *work*. I understand the concept of the Internet pre-existed his influence on the IETF process, but he is the one that demonstrated how to make it work in a large scale.
Ok, on top of Nagle's work, you have to add Van Jacobson's work on TCP Congestion Control. And all the work that Mr. Jacobson and other did to make improvements to TCP that have made TCP much more functional (actually usable?) in a global network. RFC 1122, and RFC 1323 are key pieces of work that must be understood if you want to make IPv4/IPv6 applications work their best over a global network. Ignorance of these standards is inexcusable for anyone who takes responsibility for applications that run across long WANs or global networks. It's inexcusable.
On top of this, you have to add a firm understanding of TCP's inner workings via RFC's 2988, 2581, and 2582. A understanding of TCP SACK options (RFC 2018), TCP Window Scaling (RFC 1323), and the impact of TCP Timestamps (RFC 1323 and RFC 3522).
-------------------------------------------------------------------------------------------
Maybe someday, I'll try to write up something that does a better job of trying to describe why pings (icmp/udp/tcp) are so important to determine whether a network is ready to run interactive applications. But, I think I'll leave it with this.
Take a PC, hook it up to a bad Internet link (line of sight wireless to a grain silo for example), load up wireshark, and get a subscription to a TCP based interactive game (like WoW or similar). Then go raid with 24 of your closest friends. You can also pick a server on the other side of the world if you absolutely refuse to get a bad Internet connection, it's close to the same effect. After a few years, you will understand.
Pings matter, simply because they show how good, or how sloppy the network is. Sloppy networks don't run interactive applications well. Everything is moving to a dependence on the network to support interactive applications from farther and farther distances.
Weialgo graphs a network and shows if it's sloppy or not. What it takes to make a non-sloppy network is hard. Sloppy networks are easy.
So, if you're having problems with your network, ping, and graph it over time. You're probably dealing with a sloppy network.
No comments:
Post a Comment