Internet = InterNOT @ Interop

我上周三在纽约，11月18日，举办了互操作场所的一天旋风之旅。很抱歉说我没有时间参加主题演讲，但我的日程计划只提供了足够的时间来赶上正在展出的二十个或所以管理的供应商。我很少知道我会被迫过当天作为一个不幸的一天 - “有没有人” - “互联网没有连接”......首先，我真的很高兴看到这么多人在过道的过道中展览。我不能确定有多少人专业人士寻找技术解决方案，vcs偷看他们的贝壳寻找新的投资，或者有多少人是寻找工作的“巨大经济衰退”的儿童，但整体效果是能量和嗡嗡声之一。不幸的是，我在我的嘴里留下了糟糕的味道，在我最终沮丧的尝试，在展厅和媒体中心连接到互联网。互操作表演始终赋予超连接，包括过去几年的免费WiFi访问。此外，有名为Management供应商，负责监控Interopnet并提供操作保证。简而言之，我试图通过802.11b / g wifi连接，以及在展会上方的媒体中心的固定以太网电缆，两者均在展会上11点开放之前，然后再次在下午4点左右再次。 I also tried connecting via 802.11b/g on the show floor in the café area during lunch. In all cases, I had trouble getting an IP address served to my laptop, and when I did get an address I could not achieve more than a trickle of throughput, resulting in timeouts and dropped connections. Overall, a thoroughly unsatisfying experience. And this despite the fact that my laptop WiFi worked just fine before and after I was at the show, and my iPhone 3G faithfully delivered my e-mail all day long without a hiccup (not using the WiFi connections – just the 3G network.) Okay -- a missed opportunity for sure -- I could have asked someone for help, but didn't. I realize the show floor is a busy place and just figured that the access would get better if I tried again later. Let's be honest -- most of us would do the same, since we have all been de-conditioned by the best-effort world of cellular phones. And I was ready to file this experience as just another inconvenience that comes with business travel now and then. But then “Official Interop Troubleshooting and Monitoring Vendor” Splunk started sending me little marketing quips about how many events were happening on the show net, how many attacks were happening, and how many iPhones were connected. Again, I was ready to ignore this as simply curious trivia, but their claim to provide "troubleshooting" would not leave me at peace. So I asked Splunk for help. Could they perhaps tell me what happened that day? They did their best, providing me with what they had on hand, and did so quickly. They sent me log file entries from the Xirrus access points which were serving 802.11b/g connections. Those entries showed me trying to get connected, showed me trying to get an IP address served, and then showed me disconnecting. If that is all you are looking for, you might conclude that I had successful sessions -- several in fact. From an availability viewpoint, I did gain access. But from a performance viewpoint, it was (as my teenager would describe it) an “epic fail.” Splunk is a management information indexing and search product, doing some frankly pretty amazing things in terms of gathering massive amounts of data across multiple domains and making it accessible. They primarily operate by consuming log data, and pride themselves on helping operators find specific details, needles in the haystack if you will, really really fast. Log data has lots of interesting and useful tidbits in it, and are most commonly leveraged for security and systems monitoring purposes. They also provide supportive information about network/service availability, but that's where it stops. The challenges we face today when it comes to network service quality, the really hard ones, are all about performance -- not availability. And log data tells you very little, if anything at all, about performance. I've given Splunk the chance to help dig into this a bit more and will include an update in a future post if one is forthcoming. I suspect, however, that the problems were not within their view. The problem could have been with the access points, but if they were it was one of congestion. But the fact that I could not get connection on the fixed line draws me to believe that there were deeper architectural problems with the InteropNet in the first place. For myself, I won't take for granted that 802.11b/g access will work at the next Interop show. Perhaps I need to look at upgrading my laptop's WiFi to 802.11n - there were two 802.11n networks at the New York show but I didn't have a way to try those. And one parting shot/word of advice for the InteropNet team – next time you select an “Official Troubleshooting Vendor,” make sure they have the firepower they need to look beyond availability. You just can’t do the job without an understanding of (or at least a meaningful viewpoint into) performance.