For open source projects, v1.0 is generally a major milestone; one that is usually well earned.  After all, in open-source software, changes between versions are incremental and it can be a long time before hitting the 1.0 milestone.  For example, Mozilla – the original, before Firefox eclipsed it and it became SeaMonkey - spent four years as “beta” versions before finally getting the 1.0 designation – and it is notable that most of those beta versions were quite usable, Like much open-source software, it kept improving but just didn’t meet the developers exacting standards for a 1.0 release until it passed a threshold.

This 1.0 barrier was just reached for WireShark, the open-source packet sniffer. 

Is it a milestone?  Perhaps it’s just the ticking of the odometer over into the 1.0 area – the changes from the previous pre-1.0 version were minor – a new experimental version on MacOSX Intel, and some security related vulnerabilities patched.  However, WireShark remains a invaluable tool for anyone working in the network space.  Bill Alderson uses Wireshark for monitoring application performance, TCP behavior, retransmission symptoms, and protocol incongruities in situations in collaboration with NetQoS’s products – or where NetQoS’s products would be considered overkill.

Wireshark v1.0 is especially important because of its free-as-in-beer-ness.  Wireshark opened up network and application troubleshooting to rank-and-file IT staff – as anyone could download and use it, rather than having to wait for the network engineer to show up on-site or waiting for a third party.  Anything that helps the IT group solve problems faster is a good idea. 

Right now, Joel Trammell, our CEO, is at Sharkfest 08 (the first Sharkfest) at Foothill College, where in addition to Gerald Combs, the original developer of Wireshark, Dr. Vinton Cerf will be delivering a keynote. 

Additionally, with April Fools Day coming up tomorrow, you have to appreciate any program that allows you to play harmless practical jokes – and details exactly how on the official wiki. 

A year ago, ITWire wrote a story about Adobe moving into the SaaS market with a free, entry-level version of photoshop… within six months.

That version of Photoshop launched yesterday. Dubbed Adobe Photoshop Express to distinguish it from the desktop-based Adobe Photoshop Elements, the service is much like Picasa or Picnik, and in fact, despite Photoshop's "pro" reputation, may actually contain fewer features than Picasa or Picnik.

Still, an "online Photoshop" has been heavily hyped for quite a while, especially among Slashdot's Linux-heavy crowd, who come in two camps: Those who bemoan the lack of a native Photoshop for Linux, and those who think the first group should just use the GIMP and be done with it.

But there are a few things that stood out: The first was that Adobe's EULA is written so that, if you should upload your photos to the "publicly accessible areas" of the Photoshop Express service, while you retain copyright, Adobe gets a "worldwide, royalty-free, nonexclusive, perpetual, irrevocable, and fully sublicensable license" to use the photos in any way they see fit.

This may cause any company with concerns in intellectual property or data security - which is all of them - to start going over EULAs for their SaaS solutions with a fine toothed comb.

It is also a bit of a milestone for SaaS, as Photoshop is the Adobe Systems flagship brand and flagship product, a household name of desktop software. Adobe's moves in that direction are not to be ignored; and we've talked about the importance of maintaining network performance even when using SAAS solutions.

The release of Photoshop may bolster those, like Nick Carr, who believe that, fundamentally, IT is obsolete, and the trend is that all software will move from the desktop to "the cloud."

I happen to think that there's nothing to fear.

By Ben Erwin

Thanks to the latest Die Hard movie, I'm still fighting the urge to unplug my microwave to foil hacker attempts. Thanks to the U.S. government, however, we have a new line of defense against kitchen appliances of mass destruction.

The U.S. government has setup a new command center in the Air Force called Air Force Cyber Command or AFCYBER. Here's the summarized mission of AFCYBER, according to Air Force Secretary Wynne:

"The aim is to develop a major command that stands alongside Air Force Space Command and Air Combat Command as the provider of forces that the President, combatant commanders and the American people can rely on for preserving the freedom of access and commerce, in air, space and now cyberspace."

There are real threats; Estonia came under attack from hackers back in April of 2007 And in September of 2007, the U.S. Defense Department said that the Chinese military hacked into a Pentagon computer network.

It's hard to tell exactly how much damage a hack into U.S. computers could do because the Pentagon isn't exactly forthcoming with information on this. A plausible scenario would be a Chinese hacker gaining knowledge about U.S. troop movement. (A much less plausible scenario would be a teenage hacker who is looking for a game company accidentally, through a back door left by a programmer who left the project years ago, activates an AI which then seeks global thermonuclear war under the pretense that it cannot distinguish between a gamed scenario and reality.)

From a network monitoring and management perspective, AFCYBER will bring a whole new level of opportunities and challenges. How exactly do you monitor the United States network? What is the United States network? There are obviously some critical assets (White House, Pentagon, Capitol, etc.), but how many "cyber security holes" exist between critical infrastructure and those who want to attack critical infrastructure? Don't we all share some connectivity medium at some level?

It gets even more interesting on the offense front. Are you confident enough in your network management/security monitoring tools to launch a missile attack on an offending host? False positives take on a whole new meaning.

If you have answers or insights, I'd love to hear them. Otherwise, I may never microwave again.

If there's one thing that we've been trying to impress, other than our abiding love for D&D, it is the idea that while a large amount of throughput is good, low latency should not be ignored. We've talked about how the idea of "chatty apps" that make lots of calls to the server for data can run slowly on a high-latency connection even when there is sufficient throughput.

But there are other instances where low latency is important as well. The biggest one by far is the financial sector.

A little more than a year ago, the New York Stock Exchange had a little glitch that caused a few seconds of non-responsive applications. The end result was that the NYSE had 3.3% loss in market value for that trading day - from a delay of mere seconds.

But even a delay of mere milliseconds can ruin a potential stock sale.

According to InformationWeek, electronic trading makes up 60 to 70 percent of the daily volume of the NYSE. Much like Olympic relay racers, a hundredth of a second is a quantifiable measure in the stock market. Trades are often queued by computer when some external factor applies - say that two brokers have both automatically set their computers to sell a stock called STOK to sell if it reaches $3.50 a share. A buyer comes along and offers to buy STOK at $3.50 a share. When the trade goes through, it's going to buy the shares from the broker - or more accurately, the broker's computer - that responded first.

But nearly all of the human elements have been taken out of the equation. Without those, the only differences between first place and second are a matter of network round trip time.

"A 1-millisecond advantage in trading applications can be worth $100 million a year to a major brokerage firm, by one estimate."

So, you can see why network performance isn't just about throughput. In the meantime, for your own network, you can check out our network latency calculator to find out what speeds you should theoretically be getting, and start working towards those speeds.

by Brian Boyko
Editor, Network Performance Daily

Apple hasn't made many overtures to business; the announcement that King Jobs had deigned to allow enterprise apps in his iPhone fiefdom took many by surprise. Apple's previous attempts at wooing enterprise customers, specifically the Xserve, seemed, in my opinion, more like a half-hearted reassurance to shareholders that they weren't completely ignoring the enterprise market.

Here's a telling point about Apple's attitude: Even though virtualization is one of the most important trends in enterprise computing, Apple makes the only operating system which cannot be run as a virtualized OS on generic hardware. It didn't allow Leopard Server to be run as a virtualized OS even on its own hardware until October 31st of last year.

While it's also true that Microsoft had - past tense - clauses in Vista EULAs which made it illegal to run Vista Home Basic and Vista Home Premium (but not Business, Enterprise, or Ultimate), as a virtual machine, those restrictions were eventually lifted in late January of 2008 - most importantly there was no deliberately imposed technical stumbling block that prevented those OS versions from being virtualized.

(One commentator, who I cannot remember, suggested that Microsoft's awkward anti-virtualization positioning was a move to prevent Apple from offering Parallels Desktop and a virtualized Vista pre-installed on new Apple consumer computers - but the ban has been lifted and Apple hasn't made any deal like that.)

Apple's MacOSX, on the other hand, checks to make sure it's running on Apple hardware, and will not run, otherwise. There are hacks to get around this, I'm sure, but they're much more difficult to pull off, may have stability problems - oh, and there's that whole "it's quite illegal" thing, too.

You can run MacOSX as a virtual server on an Xserve. But then it gets back to the application developers.

Enterprise application developers know today that they can pretty much choose their choice of platform. Have a Linux app but want to sell it to a Windows shop? Virtualization comes to the rescue. Windows applications on a Unix flavor? Again, same deal (though developers might have to pay for a copy of Windows to bundle with virtualized apps if the company doesn't already have a Windows virtual machine running.) But this incentive does not exist for the Macintosh platform. Who would develop a networked server application for the Macintosh platform knowing that you can only sell it to a company that made a big investment in Xserves? Especially since you can just code it for Linux or Windows and let Apple-only shops run it in virtualization.

Additionally, Microsoft has developed an optimized Windows Server 2003 version for virtualization - the Datacenter edition, and various Linux developers have scaled-down versions of the Linux OS for virtualization, including Ubuntu JeOS. We were not able to find a stripped-down version of Apple's Leopard Server. At any rate, running a "full" operating system in virtualization increases overhead and can impact server response times and, therefore, application performance.

Since there's this disincentive for enterprise application developers to develop for the platform, and a comparative performance hit on the platform that should cause network engineers to think twice about the platform, what, exactly is the utility of a MacOSX server?

I'll be frank - I couldn't think of a good idea for an article today. There are a couple of interesting links in the news, of course, which I could share with you. And we will get to those in a second, but…

…truth is, I wanted to get a little introspective about things.

This blog is based on Movable Type v.3, and while we can talk about what I should have done, switching to a different system, such as WordPress really didn't make a whole lot of sense.

The one problem that MT had was that we were getting deluged with spam. Hundreds of spam messages a day.

Now, there is a setting that is supposed to catch junk posts. However, this was worse than useless, as it didn't catch a great deal of the junk messages - and it was classifying some good messages as junk mail. In fact, I think it might have been classifying most good messages as junk mail, which may be one of the reasons that we didn't get many comments on this blog for - oh, the first 16 months or so.

A few weeks ago, we moved to a CAPTCHA based system, using ReCAPTCHA. This has been working well - we've gotten more comments, more frequently, and spam is almost entirely gone. Yeah, I know CAPTCHAs are a pain, but it's the only solution we can think of at this time.

Still, 16 months of bad comment moderation may have discouraged regular readers from becoming regular commenters. What I'd like to ask is that, if you've tried to comment in the past but got discouraged, try it now. And if it still doesn't work, for whatever reason, feel free to send me an e-mail to my work address, brian.boyko@netqos.com. I really could use your suggestions for stories to investigate or issues in technology to talk about.

That said, here are those interesting links:

New York Times: Hopes for Wireless Cities Fade as Internet Providers Pull Out:

EarthLink announced on Feb. 7 that "the operations of the municipal Wi-Fi assets were no longer consistent with the company's strategic direction." Philadelphia officials say they are not sure when or if the promised network will now be completed.

For Cesar DeLaRosa, 15, however, the concern is more specific. He said he was worried about his science project on global warming.

"If we don't have Internet, that means I've got to take the bus to the public library after dark, and around here, that's not always real safe," Cesar said, seated in front of his family's new computer in a gritty section of Hunting Park in North Philadelphia. His family is among the 1,000 or so low-income households that now have free or discounted Wi-Fi access through the city's project, and many of them worry about losing access that they cannot otherwise afford. Philadelphia officials say service will not be disconnected.

"We expect EarthLink to live up to its contract," said Terry Phillis, the city's chief information officer.

The problem was that EarthLink's plans required more routers than they initially predicted, which makes me wonder if those predictions were tested on smaller scales first. However, there is no problem with the technology - it performs as advertised. The problem is that there's no real clear way to make a profit from that technology - which, to me, makes it an ideal service that the municipality should provide, rather than outsourcing it to a private company.

George Ou: Fixing the unfairness of TCP congestion control:

George Ou at ZDNet claims that "swarming" is causing a significant bandwidth problem, and goes to great lengths to explain why, in a four page article.

Simply by opening up 10 to 100 TCP streams, P2P applications can grab 10 to 100 times more bandwidth than a traditional single-stream application under a congested Internet link. Since all networks have a bottleneck somewhere, a small percentage of Internet users utilizing P2P can hog the vast majority of resources at the expense of other users. The following diagram illustrates the multi-stream exploit in action where User A hogs more and more bandwidth over User B by opening more and more TCP streams.

But as I read it, it seemed a bit dubious to me. After all, if my multiple TCP-stream connection on my home computer allowed me to have multiple bandwidth links, wouldn't that mean that a download on BitTorrent of a Linux distribution operating at max capacity would be faster than a single TCP stream and FTP connection to a server? In practice, I've found that both speeds are roughly equal - except when there's a lot of demand on the server side; like the first few days after a new Ubuntu version comes out. Then the multiple TCP streams come in handy because they are coming from multiple TCP connections to different locations. But it's impossible for the multiple TCP connections to take up more bandwidth than had been allocated by the service provider under their QoS policies.

Where there is some validation to this is when the pipe gets completely congested to the point that the available bandwidth per user is less than the bandwidth allocation provided by the ISP to the individual users. In other words, it only occurs when the provider has under-provisioned for the network demand and is delivering less than promised to begin with.

Ou suggests an update to the TCP/IP stack that prevents this problem, but for ISPs, the solution is simpler. Either add more bandwidth so that you can deliver the service promised, or promise less if you can't deliver.

PC World: Tech Workers favor McCain, Obama:

Not getting into politics, but this little fact from the article is interesting:

The survey, of 600 self-identified IT workers, found that 27 percent have used the Internet to contribute to a political campaign. By comparison, less than 0.3 percent of U.S. residents have contributed more than US$200 to a U.S. political campaign during the 2008 election cycle.

Which implies that the techies, who by definition are likely to be Internet savvy, are highly politically motivated and therefore very interested in events from the 2008 presidential race.

Hmm, did you experience a bump in recreational network traffic around the time of Obama's speech on race?

by Brian Boyko
Editor, Network Performance Daily

Baseline magazine recently put out an article warning IT departments of under-30 "risk takers." Of course. Why not? Everyone knows that the youth are stuck up, and don't fit into corporate culture.

Being 29 years old a week from tomorrow, I was keenly interested (if giddily bemused) in what pejorative things they had to say about us brash young kids who are Ruining-It-For-Everybody™.

"Millenial workers are nearly twice as likely to use personal devices such as cell phones, PDAs and laptops in the workplace as their older counterparts."

Yes, from a security standpoint, an infected laptop or smartphone could provide trouble for the security of the network. But that also means the under-30s are more connected.

Let's look at this from a holistic standpoint. Yes, network security is important. But if personal computers and handhelds provide a more efficient way to get information, they enhance the power of the network. IT is about application delivery - and mobile devices might just be the most efficient way for Young Turks to get to the application. Yes, they can cause problems, but a NOC with automatic reporting can identify the problems quickly enough that the benefits of the always-connected employee outweigh the risks.

"Millenial workers are more than likely to use their work and personal computers for professional and personal use."

I admit that I do this. Sometimes, I need to use my personal Mac to edit video for work, or I need the computer at work to execute a Windows program. But again, this makes me more efficient. I often (after hours or on my lunch break, of course) use my work computer to send personal e-mail, and in fact, is one of the reasons I use Google Mail. Conversely, I log into Exchange to check, and send, work related e-mail from my personal computer at home if something needs my attention.

"Millenial workers believe they should have the right to use software of their choice on their work computers, regardless of its source."

NetQoS has a policy of allowing everyone to install whatever (legal) software they deem necessary to complete the work (as long as it doesn't affect other's network performance). As research for articles I write, I've got a variety of freeware programs, including GIMP, VirtualBox (virtualization software), various video editing programs and, the big one, Firefox, which I downloaded on day one. (I will never understand companies that make you use Internet Explorer in the name of "security")

I've worked at places where we were severely limited in the programs we could have. There's a reason I'm not working at those places anymore - the lack of trust in the ability for a person to choose their own software - their own tools - shows a lack of trust in the ability of the person. And it paints IT as productivity preventer rather than enabler.

This is not to suggest that there should be complete anarchy on the network. But when the IT department locks down everything, it creates more of a productivity hassle than any damage that a virus or hacker can do. There are unsecure apps out there, and the good judgment of the majority does not make up for the poor judgment of the minority. But with that said, why punish the majority for the transgressions of the minority.

It is not, after all, the downloading of malicious apps which affects the network - it is the traffic that those malicious apps produce. Instead of trying to control the application on the desktop (and relying on security on the user/desktop level is futility at best) it's better to control access to the network. You can put computers with out-of-date antivirus or unauthorized apps on an alternative network. You can use anomaly detection to find malicious traffic before it does damage. But there are a whole host of options between application anarchy and resorting to the draconian measures of a culture of complete control.

"While Millenial workers are more likely to visit unauthorized Web sites and install unauthorized applications, they are also more aware of security risks then their Gen X counterparts."

"Millenial workers are slightly more aware of what it takes to secure their apps and devices."

These could easily translate as: "Don't worry. We know what we're doing." And while those have been famous last words a number of times, in this case, I don't think it's ironic. But more importantly, security should never be left to the end-user. We've tried it countless times, it doesn't work. If you rely on defenses at the edge, your network is only as secure as your least security savvy employee.

This next one is very important:

"While all workers want access to technology and devices, each group reports little to no productivity gains as a result. Millenials, however, are more likely to perceive productivity gains from collaboration and Web-based apps." [Emphasis added]

When you think of Web based apps, you immediately consider the network. This is a generation raised on MySpace and Facebook, and Google Maps, and Google Mail, and Google Analytics, and Yahoo Answers, and Wikipedia - this is the generation of the Web based app. These are the tools that the upcoming generation is comfortable with. And the people who develop tools know this. This is why application performance - especially for Web based apps, is so crucial.

In the end, Baseline put out a separate article a few days later, pointing out that under-30s in IT had benefits as well as drawbacks. But why should we believe them? Everyone knows that you can't trust anyone over thirty.

Bruce Schneier, contributor to Wired Magazine, recently wrote about the security mindset in an article entitled: "Inside the twisted mind of a security professional." I really do recommend you read the whole thing - it contains very practical advice about security - computer and otherwise. But by all means, do please come back, eventually, because I think I have a good inverse point.

Schneier's article explains the always-looking-for-loopholes "security mindset."

Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it….

This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems. …

The designers are so busy making these systems work that they don't stop to notice how they might fail or be made to fail, and then how those failures might be exploited.

The only point that I disagree with Schneider on is that most people don't have a security mindset. Ultimately, I believe that they do - and this is not cynicism - but that we, as human beings, are wired to fear the risk of a big loss. Perhaps we don't go about thinking of how to beat other people's systems evaluating other people for weaknesses and constantly planning escape routes, but I think we do think about how we protect our own property and family.

According to Schneier, that's not enough, and I agree with him. He's right in saying that thinking about how things can be made to fail is too often limited to the mind of the security professional. But, inversely, thinking about how things can be made to work is too often limited to the mind of the engineering professional.

Indeed, engineers see things differently as well. Instead of seeing things for what they are, they see things as they could be. Engineers are the people who make things and make things better. Geeky, to be sure, but they're the guys and gals who overclock home computers and build old computers into Beowulf clusters. They're the guys who compared torque and horsepower on automobiles during the 1970s and now compare fuel efficiency and aerodynamics on automobiles today. Hell, even in gaming, from D&D to Monopoly to World of Warcraft to poker - engineers see things to the maximum benefit from the minimum cost.

This isn't just a mindset, this is a culture. And I may be wrong - and I don't say this to disparage the network security guys. But I don't think a mindset that consists of finding the breaking point and tearing things down can create as much of a vibrant culture as exists among engineers and those who think like engineers. You can't build through destruction.

But again, the human mind is geared towards risk, which is why, as a topic of discussion, and especially on the Internet, network security (protection from failure) is more of a hot topic than network performance (improvement from the status quo).

Network monitoring can be done for preventative purposes, certainly. If a router goes down, you want to fix it as soon as possible, and reducing the mean time to repair is always a worthwhile goal. And if that's all that IT did with network monitoring products like ours, that's good - but what we really like to see is people taking the information for new ideas about how to organize the network based on the application response times they're getting.

Or put another way, the same paintbrush that protects the house with a coat of paint can create the next Mona Lisa. It just requires thinking about creating.

The ultimate function of the IT department is to provide delivery of the business critical applications in a speedy and reliable manner to the users who need them. Virtualization doesn't change that. It merely changes everything else.

The funny thing about a virtual server is that it is the living embodiment of the idea that the silos in IT have to break down and once different technical fields now have to work together.

Virtual servers are part of virtual networks - that is, there are multiple virtual servers on one actual piece of hardware, and they connect to each other - on the same hardware - using the same networking protocols that they would use if it was communicating with a server halfway around the world. But it's all on the same server, so here's the question: Who fixes it when it breaks? Who owns it?

After all, there's no actual fiber/copper/tin-can-and-string wiring going on, it's all entirely on the server. So is it the server team that is responsible for "intra-box" networking connections? Or is the network team responsible? Gumming this all up - virtual servers are software. Does that mean the application team should be the one responsible?

With virtualization, you really can't have a segregated IT department and continue to operate efficiently. Traditional models of which part of the IT department "owns" which part of the "application path" from server to user are now irrelevant.

We've been talking about the idea that server, application development, and networking teams have to merge into an application delivery team for quite a while now - we invited Jim Metzler to speak at NetQoS Symposium 2007 to talk about it, and he'll be back for NetQoS Symposium 2008, (which starts a month from today, actually).

I think virtualization has thrown everyone who works in the enterprise space - from network engineers to CIOs to vendors like us here at NetQoS. Everyone knew it was going to be big; I don't think anyone realized how quickly it would catch on. March's issue of CIO Magazine reports that 85 percent of CIOs are happy with the return on investment of virtualization - even though it can be hard to quantify exactly what the return on investment is with current tools.

We're releasing NetQoS VoIP Monitor v1.1. Biggest changes: SIP (Session Initiation Protocol) support, automatic and on-demand problem investigation, and capacity planning reports.

I want to start with SIP support, because there's an interesting related story that caught my attention when it came out on Slashdot.

One of the odd things about SIP is that it is, to some extent, a peer-to peer based protocol. The advantage of this is that it only requires a simple core network, with all the fiddly bits distributed to the network edge. This makes SIP more scalable than other protocols. You can see why our customers think SIP support is important and why NetQoS worked to put it into this release.

But as a side effect of the way the technology was designed, SIP's peer to peer network means that it can be difficult to route emergency calls because of the mobility of IP endpoints and the fact that SIP has no network location capability - you'll remember that Vonage got into a little bit of trouble a while back because it couldn't consistently promise E911 support. (That has since been fixed.)

SIP also establishes a VoIP connection directly between the two calls out at the edge. Once the call is set up, the data does not pass through any sort of central server owned or controlled by the VoIP provider. That makes it harder for the government to legally (or whatever) intercept calls.

I mention this because the actual documents governing the rules behind U.S. government interception of VoIP was leaked to Wikileaks on the 15th of March. Now, this is nothing new - CALEA requires VoIP providers to maintain wiretapping capability - just like the plain-old-telephone-service providers are. It's interesting, however, to see the documents. Or at least it might be to somebody else who is interested in network security and encryption.

But from a performance angle, the CALEA requirements for wiretapping are directly in opposition to the efficiency of a SIP VoIP network - that is, if a service provider must be in the middle of every call, it eliminates the benefits of the P2P structure. That adds a lot of network overhead.

The other new features in VoIP Monitor v1.1 are generally less conversation sparking - but no less important. Most of our other products, such as SuperAgent, have both automatic and on-demand problem investigation and capacity planning reports. These capabilities have been added to VoIP monitor in the new version.

Automatic investigations occur when a VoIP performance threshold - such as delay to dial tone - is exceeded. Then VoIP Monitor traces the call signaling path and compares it to the automatically generated baselines.

As far as capacity planning reports helps go, VoIP Monitor v1.1 providers enhanced reports on call volume, call quality, call failures, grade of service and gateway utilization. It provides a view of the effect of different call volumes. With this information, IT professionals can view capacity for specific locations or gateways or for the enterprise as a whole - the utilization reports are especially useful when negotiating contracts with service providers.

We have a demo of VoIP Monitor v1.1 up and running at VoiceCon in Orlando, at booth #1305, if you're attending.