Airlines and Queuing Theory

I remember my first days of working on TCP/IP networks back in the late 1980s as days of wonder. I used to sit at my desk in Palo Alto, California and marvel at the ability of having one telnet window logged into a router in Singapore and another logged into a router in Puerto Rico. Watching ICMP Echo packets (pings) travel to each location in well under 500 milliseconds (today around 300 to Singapore and 180 to Puerto Rico) simply always made me smile - especially since I could name almost every device those packets went through on both routes on the private network where I plied my trade. Those were the days before the Internet was how it is today and before we ever heard the phrase "Information Superhighway" (I saw Al Gore on Letterman last night and that conjured up that little tidbit).

TCP/IP networks of that era were slow and always congested. A super fast link was a T-1 and those were exceptionally rare. Think about an international network with the capacity of your basic DSL circuit on most links. Because of the limited bandwidth we often deployed lots of queuing algorithms to make the network work in the manner we wanted. A co-worker of mine is fond of saying, "You only need to queue when you have congestion." And we had congestion 24x7. So, over time we used forms of committed access rate (CAR), flow-based queuing, weighted-fair queuing (WFQ) and others. Some of these queuing techniques are being added to the Vyatta OFR and are some of our top enhancement requests. So, apparently, there are lots of you out there that want to use queues in the OFR to avoid congestion for specific applications, such as voice.

But, what in the name of FDDI does that have to do with airlines (you may ask if you read my subject above)? Well, I'm lucky enough to be sitting in an airport at the moment waiting for an inbound flight from San Francisco to arrive so the airline can turn the plane around and use it for my flight home to the city by the bay. And, up to about 30 minutes ago the airline was reporting that my flight was an on-time departure (so I came to the airport like a good drone for my on-time departure). Of course, until 30 minutes ago my flight was on-time according to the airline. Just so we're clear - this is a plane that left San Francisco over 6 hours ago. And, amazingly enough I just found out that 6 hours ago it left San Francisco about an hour late. Just so you follow me here, if a train of packets are delayed because of a queuing issue, the receiving end can sense this and adapt to handle the slower arrival times of the packet train (see basic TCP flow control in operation). And the protocol does this multiple times every second (thousands and thousands). So, was my arriving plane going to hit a time warp and make up the hour delay in flight to make my departure on-time? Maybe I'm being dense here, but if TCP can adapt to packet queues many times a second why can't humans do the same once in a six hour time period?

Maybe I need to know exactly what plane the airline will be using for my departure so I can track it's inbound arrival as I head to the airport? Now, that would be cool - an airline website that tracks planes by transponder signal and correlates that next departures. Or, the airline could just get a clue and update their departure times appropriately for their customers.... Okay, that was just bitter, but it felt good given my current situation :)