An interesting post over at Slashdot pointed me over to a Network World story by Mitchell Ashley about how Windows 7 wouldn’t be a compelling upgrade from Windows XP. The interesting aspect is that Ashley goes on to suggest that perhaps the idea of OSes might become irrelevant if you move to thin clients connected to virtualized computers over the LAN.

The future Simon paints is one where these personal and business computing environments are virtualized onto the same computer, rather than intermingled as they are today. Businesses will deliver virtualized full OS plus apps, and stand-alone virtualized apps, to computers that users own. This maintains the security of corporate data and applications, and allows the business to viably deliver a computing environment they manage on computers they don't. Obviously this vision is in line where Citrix is going with XenServer, XenApp and their newly announced Project Independence, and given my own views about desktop and application virtualization I can see merit in a lot of Citrix's vision.

While we haven't seen much of this yet, I believe it would be wise for Microsoft to continue to improve Windows 7 as an easily virtualized OS and a platform for delivering virtualized applications. Microsoft has partially move Live Essential apps into the cloud. As they move Office and other apps online, the OS becomes thinner and thinner, less bloated with applications that entangle themselves into the registry and Windows folder of Windows 7.

You know what, I might be wrong on this – but I don’t see it happening.

This is not to say that thin clients and virtual desktops don’t have their place, but the problem with virtualizing the desktop is that offloading processing to a datacenter means, necessarily, more traffic on the LAN. Individual applications may be run remotely, sure, but operating systems – or specifically the graphical user interfaces of those operating systems – carry a lot of overheard. (If we were all using command line interfaces, the overhead would, of course, not be nearly as great.)

Additionally, companies have been moving more towards having consolidated servers connected to the end-user via the WAN – by bringing the servers closer to the datacenter, you’re also, in effect, moving the users further away. You can have virtualized desktops saturating your LAN, or virtualized servers saturating a WAN, but it would be extremely unlikely that you could have both on the same WAN.

What seems more likely is the use of virtual servers to serve up specific applications – applications that can be optimized to reduce overhead on the network. I just don’t see that happening with XP, nor Windows 7 – perhaps only the next generation – the Microsoft Cloud OS, perhaps – might be light enough to handle virtualized desktops. Then again, a computer’s what, $300 from Dell nowadays? And are you saving that much if you have to get a thin-client appliance for each user instead of buying a general purpose PC?

There have been some worthwhile attempts to do the WAN equivalent of having a cake and eating it too - a number of WAN Optimization vendors are putting in Windows services on the WAN Optimization blades themselves.  That is, one of the ways they optimize the WAN is to keep traffic off of it – and one of the ways to keep traffic off the WAN is to take care of Windows services on the branch LAN, before it even reaches the WAN.  In a way, it’s sort of the opposite of server consolidation – but since you have to run the blade for WAN optimization purposes anyway, you’re not adding additional hardware or sucking up much more power. 

This is pretty much speculation at this point – but speculation is fun, isn’t it? I’d love to hear your comments on this.

By Patrick Ancipink

So far, so good at Cisco Networkers in Barcelona this week. Despite spirits being a little tempered by the worldwide financial crisis, attendance seems to be quite good and we are noticing a radical shift in what enterprises and service providers are trying to accomplish with their networks.

One topic that’s a bit been very popular with this audience is the concern about VoIP and video quality on converged networks.  So you could say network pros are more jittery here about latency-sensitive UPD applications than they are about the macroeconomic situation.

Heh…

Moving on...

The primary concern about video has shifted from quashing recreational YouTube viewers to ensuring the network can carry video. We spoke with several different companies (with headquarters from Sweden to Qatar) that have requirements to stream video across the WAN as part of their mission. I was involved in several conversations and overheard several more where the main topic was using application-aware network management tools and techniques like IP SLA and how to determine, validate and assure QoS.

I have to say I was pleasantly surprised about the awareness of the Cisco NAM support we announced the day before yesterday. It seems like before the news even hit the wire we had several attendees asking how they could use their NAMs alongside NetQoS. There are some monster implementations of NAM out there so everybody’s happy when you can leverage the existing investment for better application response time monitoring and performance troubleshooting.

Tapas and Rioja are nothing to complain about either.

We recently praised Comcast for coming up with a solution to congestion while remaining platform and application agnostic. To recap: Comcast’s new policy is to lower the class of service on packets sent or requested for those users who are currently using more than 70% of their bandwidth over a 15 minute interval only during times of congestion. 

However, the FCC doesn’t necessarily agree – they’re asking why VoIP calls made on Comcast Internet might be choppy during times of congestion – but Comcast’s “Digital Voice” service won’t be choppy.

There are a number of issues; but ultimately, the reason why Comcast’s Digital Voice service is being treated better than other VoIP services is that the Comcast service travels on Comcast-owned pipes as far as possible before connecting to the general Internet.  Since Digital Voice traffic isn’t considered “Internet Traffic” it won’t matter when determining whether a particular user has been saturating his or her connection during times of network congestion. 

This argument may get Comcast out of trouble as far as net neutrality is concerned, but when making a voice offering distinct from that of the general internet, the FCC may rule that the service is a “telecommunications” rather than an “information” service.  That means being subject to different governmental regulations. 

Comcast isn’t the only ISP looking for ways to prioritize traffic and deal with congestion; Cox communications has announced that Internet users in Kansas and Arkansas who are using “time-sensitive” applications or services (we suspect it’s layman’s speak for “latency-sensitive” purposes like gaming, VoIP and teleconferencing) will get priority over downloading files during congestion periods. 

Though the coverage in TMCnet states that Cox “entered into the Net Neutrality arena” the solution to prioritize traffic seems sufficiently neutral to us – the prioritization is not based upon the particular application but on a class of latency sensitive applications (possibly determined at the transport layer [layer 4] rather than the application layer [layer 7]).

It will be an interesting study to see how the two different measures stack against each other; perhaps we might get some good data on how effectively the different policies tackle the same goal.

Today we just put out a press release and went live with a Web page announcing our integration of SuperAgent application response time monitoring into the Cisco Network Analysis Module (NAM). The integration combines NetQoS SuperAgent’s ability to baseline and analyze application performance across the entire network with the NAM’s high-resolution troubleshooting capabilities and data collection capabilities.

Or in short, instead of having a NAM and an external SuperAgent collector(s), you now have the ability to have both in the same box. Isn’t that swell?

The NAM monitors and analyzes network traffic, and provides Layer 2 to Layer 7 visibility into the network traffic. The benefits of combining Cisco NAM with SuperAgent are summed up by Paul Hoyle of the California Department of Transportation WAN Management team, which has already tested the combination. Hoyle said:

“We will be able to combine the data from our multiple NAMs with our other SuperAgent collection sources and view it all in the NetQoS management console, which will help us better understand how applications are performing across our organization and quickly drill down to any NAM for efficient troubleshooting. Plus we get the benefit of monitoring more applications without having to deploy additional SuperAgent hardware.”

As a tag-team, Cisco NAM provides visibility into network and application performance to help ensure the consistent and efficient delivery of applications and services. SuperAgent then takes that information, and delivers an enterprise-wide view of performance, volume, and availability metrics across all of the NAMs (plus SuperAgent’s own collectors) in the network, as well as the ability to drill into each NAM user interface for high-resolution diagnostic reporting. SuperAgent also automatically investigates the cause of problems in a way that augments the NAM diagnostics. For example, SuperAgent can immediately launch a trace route investigation when network latency increases above a normal baseline.

By Steve Harriman

Last Tuesday, Riverbed, known primarily for Steelhead, its WAN optimization controller (WOC), acquired Mazu, known primarily for its network behavior analysis detection (NBAD) tool Mazu Profiler. Riverbed said that they’re planning to integrate Mazu’s technology into their own products.  Similarly, Blue Coat, another WAN Optimization vendor, announced earlier today that they are going to partner with Lancope, another NBAD vendor, for much the same reason.

Before the acquisition, both Mazu and Lancope had been retooling their messaging – moving from a security focus to a more of a network performance monitoring focus in an attempt to appeal to a much broader market. In the long term, it’s likely that NBAD is unsustainable as a standalone market – but could be part of the broader set of network performance management disciplines. It appears that the WAN optimization vendors agree and are becoming interested in expanding their performance management capabilities. Indeed, Blue Coat already demonstrated this with its 2008 acquisition of Packeteer. In hindsight, it’s a little strange to see network performance monitoring and network behavior analysis as two separate fields. 

However, these flow-based NBAD technologies should not be confused with the Cisco-NetQoS technology in Cisco’s WAN Optimization offering--WAAS. In July of 2007, Cisco and NetQoS jointly developed instrumentation for WAAS devices that feeds key performance data to our application response time monitoring product SuperAgent.  SuperAgent was designed from day one to track application-by-application, subnet by subnet, the end-to-end performance of applications running over WANs, and merely had to be adapted to the optimized WAN environment. The SuperAgent-WAAS integration restores visibility into optimized WAN links which create unique visibility problems by breaking the TCP stream up into three separate streams. Without instrumentation in the WAN Optimization Controllers (WOC), you need to have monitoring equipment on both ends of the optimized connection. That gets expensive, so it makes sense to have the monitoring software embedded (at no additional cost) in the WAN optimization equipment. 

Without this tight integration, you can still derive a lot of performance-related information from the WOCs as long as they export standard network flow datagrams, notably NetFlow or IPFIX. This data provides visibility into traffic composition across the optimized link so you can see what effects the WOCs are having in reducing traffic. However, it doesn’t tell you anything about the end-to-end response times so you can’t tell if they are better or not (which is severely disappointing if that’s why you bought the WOCs in the first place). NetQoS customers use our ReporterAnalyzer product to monitor NetFlow/IPFIX exports from these WOCs, including those from Cisco, Riverbed and Blue Coat.

It’s not just enough to optimize a WAN connection and hope for the best. If your WOCs–from whatever vendor you choose—are to be effective, they should be monitored. In fact, it’s really smart to monitor your links before you deploy WAN optimization gear so you know which remote sites are the best candidates and to give you baseline performance statistics. Performance monitoring not only helps you measure the performance improvements you’re getting, it helps you solve problems faster.

Given this, it may seem strange that Riverbed would be interested in NBAD technology which gives it NetFlow visibility but not latency visibility across the three segments of the optimized WAN link. We should assume that Riverbed will use its newly-acquired technology for more general purpose monitoring and expand its capabilities over time. Interestingly, Blue Coat’s roots are in the security space and it’s quite likely that Riverbed’s acquisition was, at least in part, intended to bolster its own security-related offerings.

NetQoS has offered NBAD capabilities in the NetQoS Performance Center since February of 2008.  

[In the interests of full disclosure: Network Performance Daily is the “house organ” company blog of NetQoS, and is competitive in the behavior analysis space to Mazu and Lancope. –ed.]

Steve Harriman is VP of Marketing at NetQoS.

Chandra Hosek, Ben Erwin, and Andrea Stout contributed to the research of this post.

The world is a small place – and getting smaller. Nobody knows this more than the people who work in networking and IT. We’re the people who are trying to connect people and bring them together. (Well, us and various diplomatic corps, but it’s a totally different type of bringing people together.)

This is all leading up to our announcement that NetQoS has worked out a distribution deal for the NetQoS Performance Center in Malaysia with the Kuala Lumpur-based Extol. This includes  SuperAgent, Gigastor, ReporterAnalyzer, NetVoyant, and Unified Communications Monitor.

Justin Tan, the CEO of Extol had this to say about it:

“The NetQoS Performance Center consists of award-winning, proven management solutions that will complement Extol’s offerings by helping our clients manage the performance of their devices, links and applications in addition to their risk and threat management. NetQoS products are reliable, easy to deploy, and scale to large networks so that our clients can monitor and improve their network and application performance.”

We’d say “aw shucks, you shouldn’t have,” but then we remembered that Extol is doing sales and marketing for us in the region, so…

Anyway, the sentiment is appreciated.

Extol is well known in the region as a security solutions provider, focusing on areas such as fraud detection, forensics and incident response, anti-virus, security systems management, and secured enterprise applications. Being able to complement that background with our network monitoring suite is a bold, logical step.

In the meantime, our technical representative in the Asia-Pacific region, Wilson Leong, presented a plaque recognizing Extol as a channel partner to Extol CEO Justin Tan at the launch of Extol's new offices. He took some pictures that we’re happy to share with you below.

It may not have made the front page because it came out on Tuesday when there was another news event that overshadowed it, but the New York Times had some big news in IT anyway – Cisco is moving into the server market.

The philosophy of the move comes down to an industry idea that with advances in virtualization technology, the data center is becoming a “single entity” rather than separate units. The demand for networking equipment might very well be reduced if you could run all of your enterprise’s servers from one or two ultra-powerful mainframes.

If this is inevitability, naturally, Cisco would like to have a piece of the market here.

“Our vision is, how do we virtualize the entire data center?” Ms. Warrior said. “It is not about a single product. We will have a series of products that enable us to make that transition.”

This has put Cisco at odds with traditional server manufacturers, of course.

So the question becomes, is the innovation going to come from the traditional server providers where networking capabilities are just another feature, or has the traditional server been so commoditized that it makes more sense to add it to the multipurpose firewall/router/floorwax/dessert-topping network gear? While servers and routers are already becoming commodities, which one will be driven even further down that commodity slope?

While Cisco may be concerned with network/server infrastructure, it’s also important to consider the impact on network/server management. If the servers and networking – from whatever angle – are becoming one, shouldn’t it be time to dissolve the barriers between network and server IT?

I don’t know the answer to these questions, and I’m hoping that if you have any insight – from Cisco, from HP, from IBM, from EMC, from VMWare, or even from Apple (hey, they have a server too!) – that you’d be happy to share it with us.

The one question that’s REALLY bothering me? How will the virtualized data center affect network performance? It’s hard enough for a “mostly liberal arts” geek like me to calculate theoretical latency between WAN endpoints. (That’s why we have a calculator.)

Are you telling me I’m going to have to learn Big O notation too?

This post was compiled with research and insight from Ben Erwin and Patrick Ancipink.

Via Twitter, John Taylor, a “public policy guy” at Sprint, “tweeted” a few interesting facts about Sprint’s capacity during the Inauguration:

Just in: Data on Sprint's performance during #inaug09. We broke records for a normal day of calls, SMS and data by 6:00 a.m.!

Sprint was the busiest between 11 ET & noon when traffic spiked 212% - 3X our normal traffic. Contd breaking records each hr til 3.

Text messaging on Sprint reached the hightest [sic] level between 11 & noon ET with an increase of 375% -- 5X the normal le vel [sic] for DC. #inaug09

We were prepared to handle 10-15 times the number of people on a normal day in DC. Boosted Nextel by 90%; Sprint by %40. #inaug09.

And, humorously enough:

Thanks! I had just 1 dropped call yesterday. Of course it was during an interview with a reporter asking about our network. ;-)

While the transfer of power was peaceful, the transfer of data was less so. ComputerWorld reports that the Web sites of ABC, CBS, Fox Business, the L.A. Times, NBC, National Public Ratio, USA Today, the Wall Street Journal, Whitehouse.gov, Senate.gov, and for some reason, NPS.gov (the Web site of the National Parks Service) were experiencing significant slowdowns.

Mashable showed that there were over 600,000 status updates through CNN’s Facebook integration, with 4,000 people commenting on the Facebook CNN feed per minute during the broadcast, with “millions” of people logged into Facebook during the broadcast. CNN broke it’s all time total daily streaming record of 5.3 million live streams (set on Election Day 2008) with more than 21.3 million live video streams. At its peak, 1.3 mllion people were concurrently streaming.

To put 21.3 million live video streams into context, the YouTube Rick Roll site has only been seen 15 million times. To date.

(No wonder Obama’s appointing a national CTO – every time the guy opens his mouth, the Inter-Tubes get clogged…)

Research on this article was contributed by Chandra Hosek and Jordan Guthmann

Throughout this blog, we’ve continually knocked Comcast for going after users who download large amounts of data, when the real problem is bandwidth at any particular time, and for going after BitTorrent users, when download protocols are independent of bandwidth. 

Both seemed to us, at the time, to have nothing to do with congestion control, and everything to do with trying to limit the capacity of the Internet to provide video which could compete with Comcast’s cable TV offerings.

But an FCC ruling against Comcast for the Sandvine-style BitTorrent throttling lead to Comcast going back to the drawing board.  This time, they’re doing what they should have done in the first place.

As past of its new congestion management practices, they've deployed new hardware and software close to the company's Regional Network Routers (RNRs). This hardware will flip a user from the standard "Priority Best-Effort" traffic (PBE) to lower quality of service (QoS) "Best-Effort" traffic (BE) for fifteen minutes if a subscriber surpasses a "User Consumption Threshold" of 70% of their upstream or downstream bandwidth bandwidth over a similar 15-minute period. Using more than 70% of your bandwidth for this duration is called an "Extended High Consumption State."

What this means is that:

1. There will be no changes to packet priority when the line is not congested.


2. The system identifies those users who are using the most bandwidth at that moment in time.


3. It places a lower priority to the packets of those heavy users.  So, in an overcongested pipe, the large file downloader (FTP or BitTorrent) will have to suffer reduced speeds at higher latency (though they will still be able to get the data) while the e-mail/web/gaming/voip user will likely not see reduced throughput or increased latency. 

This works.  This is what we’ve been telling people.  It is a platform, application, protocol agnostic method of choosing who will have service reduced during times of congestion.  It attacks the limited resource – bandwidth – without attacking the unlimited resource of data.  It only takes effect during times of peak usage. 

Finally, Comcast gets it. 

Just some quick notes on the inauguration – Cellphone providers are rolling out portable cells to handle the traffic of phone calls, photos and 3G/Edge data.  Major bottlenecks expected in DC area WiFi networks.

Took a sneak peek at MSNBC’s streaming coverage (though I really aughn’t).  Already – 90 minutes before showtime, the video plays, but is jerky and low-framerate.  Don’t think the bottleneck is on our end – if it’s not, it implies either people  rushing into MSNBC site for video, or MSNBC is lowering the bitrate of the livestream to compensate.  Do not remember having these problems on election night.  Then again, election night was at night, when people were home from work, watching TV – not at work, watching the computers.

Just a reminder: Not too late to set up a TV in the breakroom. Or if it’s too late to get a TV, set up ONE computer in the breakroom and let everyone watch that one.