By Brian Boyko
Greetings from Las Vegas, where the NetQoS team is getting ready for Interop, which starts tomorrow at 10:00 a.m.
After crossing the Southwest via airplane, and a slight snafu checking into my room, I was able to start taking a couple pictures to share with you guys from the Interop conference.
(Continued...)
Continue reading "Interop Coverage, part one" »
Check out our update of this story with added editorial commentary.
*Another update on Wafaa Bilal and Recreational Network Traffic
By Brian Boyko
I recently interviewed Wafaa Bilal, an Iraqi-American who teaches at the Art Institute of Chicago. He's currently part of an exhibit there called "Domestic Tension." There may be a lesson there for those who work in consolidated data centers.
Bilal moved his entire living room into the gallery and now spends 24 hours a day, 7 days a week over 30 days in an enclosed space, and his only companion is a paintball gun hooked up to a Web cam, which can be aimed and fired by people who go to a Web page.
And over the past 13 days, there have been over 6,500 shots taken at him. Some near his head - which, because he doesn't wear any protection other than goggles, can cause serious injury.
Even though shooting a man with a paintball gun over the Internet probably won't kill him, it seems to me to be more than art - but also a psychological test about the human condition. People who choose to aim and fire the gun at him are doing so knowing that they hurt him - but either they show no remorse when they inflict pain - a hypothesis that I'm not keen to accept but would be foolish to dismiss - or because the distance and remoteness of the location "on the Internet" is dehumanizing, and people do things anonymously behind an IP address that they'd never do when people can see your face.
While it may not be as extreme as shooting paintballs at end-users, IT departments are notorious for having staffs that are removed from the concerns of the people who actually use information technology they provide, create, and maintain. But at least an IT staff usually worked in the same building as the people they served - now, IT staffs can be continents away in a consolidated data center. With the tyranny of distance creating a dehumanizing factor, it's just that much harder to remember that the end-user experience is really what matters in maintaining a network.
The interview with Wafaa Bilal follows.
(Continued...)
The Connecticut schoolteacher convicted of four counts of endangering a child after what her legal defense contends was a pop-up infection showed minors lewd photos, will be sentenced on Friday, May 18th, after a long series of delays.
The conviction itself prompted a large amount of media coverage, especially among bloggers, but because the sentencing date has been delayed multiple times, the story has more or less fallen off the radar. We've been following the Julie Amero case frequently and whatever you feel about the innocence or guilt of Julie Amero, the case has far-reaching implications for IT departments that work with minors.
We also hope to revisit the case after the sentencing.
Previous Coverage:
By Brian Boyko
In an effort to reserve expensive network bandwidth for mission-critical uses, The U.S. Department of Defense (DoD) is banning MySpace, YouTube, and other social network and high-bandwidth media sites from being accessed via the DoD's computer network.
From CNN:
"These actions were taken to enhance and increase network security and protect the use of the bandwidth," said Col. Gary Keck, a Pentagon spokesman.
The Pentagon said that use of the video sites in particular was putting a strain on the network, and also opening it to potential viruses or penetration by so-called "phishing" attacks in which scam artists try to steal sensitive data by mimicking legitimate Web sites.
"The U.S. Army's not going to pay the bill for you to get on MySpace and YouTube," said Maj. Bruce Mumford, of Chester, Nebraska, who is serving as the brigade communications officer for the 4th Brigade, 1st Infantry Division, in Iraq.
The news of the rich media site ban has made it to the front page of Web sites such as Digg.
Tim Madden, speaking for the Joint Task Force-Global Network Operations (JTF-GNO), said this was a proactive measure - not a reactive one, and that the idea was to maximize the availability of DoD applications, and that one way to do so was to limit recreational bandwidth.
"We want to maintain the ability we have for the job we do," Madden said. Banning high-bandwidth services is one way to decrease bandwidth consumption, but there are several problems with this approach - it can be circumvented through proxies, it does not prevent people from going to alternative high-bandwidth Web sites, and whenever you create a policy, you have to spend time and money enforcing that policy.
An alternative to this is setting up separate Quality of Service levels for mission critical and non-mission critical data. When asked about this possibility, Madden referred to the ongoing Network Neutrality debate and said that "we're not going to offer a tiered network."
"Our focus on this was to maintain bandwidth availability," he said, "not to restrict it."
Although he was unwilling to discuss specifics, he said that JTF-GNO's research predicts a substantial improvement in network quality.
Some people, when they want to test the resistance of rubber-soled shoes, take the shoes to a lab and perform tests under controlled conditions. Others stand outside in the storm and hold up a lightning rod.
Similarly, when Xoops.org's servers needed to be load tested, instead of relying on canned data, they posted to Digg.com, notorious for the Digg effect, and asked for help performance testing their server under high load. The posting got over 2,000 diggs, and ended up on the front page of the site where, as expected, the site got hammered. We interviewed James Morris, one of the volunteer server administrators for the Xoops.org site, via IM, to ask him about his experiences.
(Continued...)
Continue reading "No Data Like Real Data: “Real-World” Performance Testing with Digg" »
from Brian Boyko, Editor, Network Performance Daily.
Kiltak at Geeks Are Sexy, a general technology blog, is a regular reader of Network Performance Daily (as I am of Geeks Are Sexy) and invited me to start posting as a contributor. Needless to say, I'm honored. I'm going to continue to maintain Network Performance Daily as I have, but contributing to Geeks Are Sexy ([G]) will allow me to share my thoughts on more general tech.
Also, I'm going to be attending and reporting from Interop at Las Vegas in two weeks, and if you'll also be in attendance and want to talk about your company's network performance and enterprise IT issues for Network Performance Daily, please feel free to e-mail me at brian.boyko@netqos.com, and set up an appointment so that we have a chance to talk.
By Brian Boyko, Editor, Network Performance Daily.
Last week, the cartoon strip Dilbert, penned by Scott Adams, did a series on corporate blogging, in which the pointy-haired antagonist tells the hapless technical writer that he wants to write a blog - then orders the tech writer to write it for him. To add insult to injury, he says that the blog doesn't sound authentic enough and that in order to make it sound authentic, conversational and human, the technical writer should write the blog in the voice of Mark Twain.
Needless to say, the Dilbert fictional blog is a failure.
So I figured that it would be a good opportunity to explain a little bit about this corporate blog to the readership and explain to you how we do things, lest our image be confused with that of the Pointy Haired Boss and his Mark Twain blog.
First, Network Performance Daily is the corporate blog for NetQoS. Its most basic function is that of house organ. We talk about things we're working on, give you info on key upcoming events, etc.
But the site is more than just a house organ. We have the opportunity to provide relevant, in-depth news as it happens, and while there are many business tech publications, no one is really focused in on network performance.
Network performance is, after all, a niche of enterprise computing, which is a niche of network computing, which is a niche of computing, which is a niche of technology.
But then again, this is the Blogosphere, famous for what Chris Anderson, editor of Wired Magazine, calls "the long tail." If people out there weren't aware of everything that went on with network performance, well, there's no reason why we couldn't share our expertise and insight with them. This blog gives us the opportunity to communicate with our customers and the public at large. It also gives us the opportunity to provide some level of education and, yes, evangelism, for the concept of network performance and measuring end-user quality of service, rather than worrying solely about uptime. Many people don't understand how important network performance is to their organization. Most don't know how to measure the performance of their networks in ways that are meaningful to their end users.
And of course, even we don't have enough to say about network performance over the WAN every day, so we bring in topics of concern to the entire IT community and generally report on what's interesting in the field of IT. Though we haven't taken a position on Net Neutrality, we do know that whatever the end result of that debate turns out to be, it means a paradigm shift for network performance. We reported on Julie Amero because we believe that knowing what content is flowing over networks is the network engineer's responsibility. Right now we're talking to Adrian Hooke at NASA about Interplanetary Internet. It's amazing what we've been able to accomplish and I'm very proud of it.
But getting back to the Dilbert comic that prompted this bout of navel-gazing…
First, anyone in our company can submit a blog post at any time. I do, in my capacity as editor, help them flesh it out and get it ready for publication by helping to take their first drafts - or transcribed interviews - and put them into a readable form. No offense, but we have some very smart, technical people who write in a stilted, mechanical style that often confuses, rather than enlightens. Other times, I interview people outside the company who have expertise in a particular area and write an article on that.
So there's the full disclosure: I may edit for grammar and help people get their points across, but unlike Dilbert's fictional blog, if you see a person's picture or byline up on the post, they were the author. No one pretends to be someone else.
The blogosphere is a new medium - in fact, my job title at NetQoS is "new media specialist." So we don't always know the right course of action, don't always have a battle plan, and many times we're just playing it by ear. But we knew one thing from the first day: You can't fake authenticity.
By Brian Boyko, Editor, Network Performance Daily.
Perhaps more than anyone else, Vint Cerf is the creator of the Internet. He co-designed the TCP/IP protocol when he was working at DARPA, and currently serves as the chairman of ICANN. Of E-Week's Top 100 Most Influential People in IT, he ranks at #20. Among the geek set, he is the stuff of legend.
So I was honored to find out that he posted a reply to one of Network Performance Daily's Tuesday links, where I made fun of the idea of an Interplanetary Internet [additional info at Wikipedia] - an idea that Mr. Cerf has been working on with NASA's Jet Propulsion Laboratory.
I was also humbled because that reply was:
Re: Space Internet - You have completely misunderstood the design. We DON'T use TCP or even IP for the long haul. We use DTN - see RFC 4838 and also www.dtnrg.org for details. We use the TCP/IP protocols for onboard spacecraft and also in low delay environments on the surface of planets but DTN for the interplanetary components.
So, on one hand, Vint Cerf read what I wrote. On the other hand, he pointed out - correctly - that I dismissed the idea of Interplanetary Internet far too quickly.
Furthermore, one of the things that I wrote in that article was that it would take about a month and a half for a triple-handshake connection between Earth and Mars. This was, quite frankly, due to a dumb math error on my part. The actual time it takes, based on an Earth to Mars distance of 400 million km, and a speed of light of roughly 300,000 km/s, is roughly 1,333,333 milliseconds - or 22 minutes - 66 minutes for a triple handshake. High latency indeed, but not the two weeks per pass I had originally thought. (Never again will I make fun of the probe that crashed into Mars because of problems converting imperial measurements to metric.) The post has since been strike-through corrected.
I can only say that "a little knowledge is dangerous" and led me to make poor news judgment.
So I offer a personal apology, to Dr. Cerf, to the people at the NASA Jet Propulsion Laboratory, and most importantly, to the readers. Following Dr. Cerf's links has led me to some information that I now find both very interesting and very relevant to people following networking and network performance.
RFC 4838 for Delay-Tolerant Networking Architecture and www.dtnrg.org are indeed very good sources of information about this protocol.
There are many benefits of adding interconnected networks to space technology. According to this Cisco press release, those benefits include improvements in interoperation and security with ground components, as well as additional flexibility in space design.
But the practical applications of the DTN protocol go far beyond space applications as the system is designed to be used among performance-challenged environments. Performance challenged environments include disaster recovery scenarios, the developing world, and various military applications.
The DTN protocol is designed to work with very large delays, including natural propagation delay, such as, for example, the delay between Earth and Mars. DTN is designed to work where standard Internet fails, by using variable-length messages instead of limited-sized packets, by using storage within the network to support store-and-forward operation over multiple paths and long timescales that do not require end-to-end reliability. This requires that space routers have the ability to retain data over a much longer period of time than a standard router, and to be able to retain that data even after a reboot. The DTN protocol also has added security (the last thing you want is Ernst Stavro Blofeld hacking into your spaceship-to-shore communications) and built in classes of service.
Applications that use DTN will also be designed to minimize the number of round-trip exchanges (and hopefully some of those development techniques will make their way into WAN environments.)
So the high-latency, low-reliability environment of outer space requires new protocols and new ways of thinking. And I can't think of anyone else more qualified to develop that protocol than Vint Cerf. After all, he's already got experience in the protocol development area.
Mr. Cerf also directed me to Adrian Hooke at NASA. I plan to ask him some questions about the technology later this week, and look forward to sharing that information with you in a future post.
For those of you who missed our NetQoS Symposium, we were able to get film of NetQoS CEO Joel Trammell’s keynote presentation on how to approach IT executives with network performance concerns. Below is the embedded video.
By John Mao
We recently released NetQoS ReporterAnalyzer 7.4. This new version was originally conceived as a maintenance release but after talking with customers, we thought it was a good idea to update some QoS policy-related features.
Part of the overall value proposition for ReporterAnalyzer is the ability to validate QoS implementation. Many companies want to monitor what applications, hosts, and conversations are within a particular class of service.
When you start to implement QoS policies, one of the problems you will face is that you may not know if there are any misconfigurations in the network. That could mean that mission-critical applications might be competing with non-critical traffic because it was placed in the wrong service level, or VoIP might not get the low latency and high reliability of the higher service levels.
In previous versions of ReporterAnalyzer, we didn't have the ability to look at unmarked or "default" best effort levels of service for traffic - a service value called "TOS 0." A main goal of this release was to deliver that functionality.
With the new release of ReporterAnalyzer 7.4, you now have the ability to quickly look at your top five classes of services, and if you don't see a particular application, you can drill in to TOS 0 to see if that application shows up in the default traffic where it's unmarked. If you do see it there, there's a very good chance there's a misconfiguration on that particular router for that interface where that application is not being flagged or marked appropriately.
Beyond that, we added the ability to support sFlow, a technology very similar to Cisco IOS® NetFlow, Cisco's flow statistic reporting mechanism. We included the ability to do this on HP devices, initially. Our goal is to expand ReporterAnalyzer to accept and receive all sorts of flow data from other vendors, and we're working on getting certified for IPFix. These are small steps we're taking to get to that grander vision of moving beyond being the standard for NetFlow reporting to becoming the standard in traffic analysis reporting.
ReporterAnalyzer 7.4 should become generally available in the next few weeks after we get some support feedback from early adopters.
John Mao is Product Manager at NetQoS
--------------
More information:
