YouTube now supports both widescreen video and 720p High Definition content.

So, if recreational network use was a problem before, hold on to your kiesters.

We can speculate on a couple of reasons for this changeover. One is competition from video services offering higher quality downloads in widescreen formats, such as Blip.tv and Vimeo. Another possible reason is that YouTube may decide to increase offerings of professionally made content – content that is increasingly being recorded in high definition formats at 16:9 ratios.

It could also be that YouTube is catering to consumer demand – many new consumer cameras also record in HD and invariably do so in widescreen format. Interestingly enough, videos that were uploaded as widescreen during the 4:3 YouTube era are now shown in full 16:9 format, such as my friend Kaci’s 16:9 video. Which makes me feel kinda stupid now for uploading all my 16:9 videos as letterboxed 4:3 videos, but there you go. Maybe the next step should be a zoom button on YouTube videos.

Now, YouTube is used for education and for commercial promotion – as the two video examples show – so it’s probably not a good idea to block off YouTube altogether, but instead try to figure out the impact of YouTube video on the network.

One of the videos that was uploaded in HD, is “Where the hell is Matt? (2008).” We downloaded copies of WTHIM? in YouTube’s standard quality, high quality, and high definition formats. We also downloaded a copy of the originally uploaded file on Vimeo, which was made available in Quicktime format.

At 4 minutes, 29 seconds, (or 269 seconds) Dancing Matt’s video:

• is 144,152 KB in the original file, (or 536KB/s)


• is 11,295 KB at YouTube’s standard quality, (or 41KB/s)


• is 33,587 KB in YouTube’s high quality, (or 124KB/s)


• and is 75,320 KB in YouTube’s high-definition quality. (or 280 KB/s)

In short, a high-def YouTube video takes up about 6.5 times the bandwidth of a regular quality YouTube video.

Right now, the HD video format on YouTube is a curiosity – few have uploaded HD videos yet, but as the market for high definition video gear continues to lower in price (you can get an HD camera for as little as $130 these days) there is no doubt that eventually HD format videos will become standard on YouTube. If YouTube traffic is a problem today, it will become a bigger one; if it is not a problem today, careful monitoring is needed to make sure that it doesn’t become one in the future.

Boy, what a difference a year makes.

“Black Friday” usually refers to the day after Thanksgiving, when retailers, both online and offline, started getting rushes of orders in order to fulfill Christmas demand. But unless you’re a Wall Street firm, for whom Christmas has come early, you’re probably cutting back on expenditures this holiday season.

Now, it’s probably referring to any Friday that you re-read your quarterly 401(k) or 529 statement.

Still, whether or not people –spend- more online this holiday season, they’ll probably be making a similar number of transactions – that is, Hershey bars instead of Godiva chocolate, Playstation 2s instead of Wiis, Go-Bots instead of Transformers…

And with every dollar counting, the one thing that retailers and suppliers can’t afford on Black Friday and Cyber Monday this year are performance slowdowns like the ones that hit Costco, Victoria’s Secret, Lowe's, and Macy's last year.

Additionally, even if you aren’t a retailer, Cyber Monday typically sends some Web traffic spikes over company networks as employees use the high speed connections work provides in order to make their purchases.

In either case, you can analyze network traffic flows to identify what traffic is mission critical, what is mission irrelevant, and what is mission impossible. After quantifying the impact of certain types of traffic on network performance, you can then implement quality of service policies to ensure that business critical apps have priority access to network resources.

We know that on Friday and next Monday, there will be a higher than normal volume of Internet traffic.  The trick is finding out how much of an impact it will have and preventing it from impacting application performance.

With the economy in a general nose dive, I figured that we could talk about something fun today. At every trade show, conference, and event with more than one vendor competing for your attention, there is bound to be “swag” – giveaways of small objects designed to be taken home and enjoyed with friends and family who will ooh and aah over the corporate logo printed thereupon.

Every industry has swag, but the tech industry tends to be very well represented, if only because geeks like toys and t-shirts. (Our “network rockstar” T-shirt did particularly well).

But how much swag is really out there? Just as a little experiment, I was wondering if you could do me a favor and gather up all the swag you’ve received over the years – all the t-shirts, funny glasses, USB drives, etc., take a picture of the pile, and send it to brian.boyko@netqos.com. I’d like to post some pictures online – especially if you’ve got an interesting story to tell about the swag.

For example, perhaps you met your spouse because of swag. Or you managed to use swag, duct tape, and a swiss army knife to defuse a bomb… who knows. Point is, I’d love to hear from you and figure out exactly what’s out there, swag wise.

So, how does this tie into network performance? It doesn’t.

What?

I can’t have other interests in the general tech industry? I’ve got to turn everything into a metaphor for the importance of measuring latency and jitter, or lowering the mean time to repair when something goes wrong? I’m a human being, not some sort of… network performance machine.

Although if you are interested in a network performance machine, check out our fine offerings at NetQoS! We’re giving away free t-shirts with each qualified demo.

Slideshow behind the cut.

Continue reading "Swagflation" »

The Ghostbusters are awesome.

They’re awesome because not only did they have to believe in ghosts, they also had to study ghosts and figure out the physics behind ghosts in order to develop the tools in order to bust ghosts. How did Egon Spengler know that an unlicensed nuclear accelerator would even affect incorporeal ectoplasmic entities? You’d think those particle beams would provide no more of an impediment to a ghost than your average wall.

Similarly, just as the Ghostbusters need to know much more about busting ghosts than the ghost hunting layperson, so too does the network engineer need to know more about busting network myths than the network layperson. And this is very important because networks often behave in unintuitive ways.

Network World has put out an article, “12 myths about how the Internet works,” which explain many of the ideas which are counter-intuitive enough to be headscratchers, but which network engineers deal with on a daily basis.

For example, just because A can reach B does not mean B can reach A, nor is it a given that A can reach C if A can reach B, and B can reach C. Every metaphor the layperson uses for the network – pipes, roads, series of tubes – kind of fails us.

But serious networking performance problems can be inadvertently created when application developers tend to believe some of these myths. For example:

4. The time it takes to initiate communications between two systems is what you'll see throughout the communication.

Thaler says many applications assume that the end-to-end delay of the first packet sent to a destination is typical of what will be experienced afterwards. For example, many applications ping servers and select the one that responds first. However, the first packet may have additional latency because of the look-ups it does. So applications may choose longer paths and have slower response times using this assumption.

This is one of the major reasons that companies might consider putting application developers and network teams into a single “application delivery” team. And to be told, choosing the server with the slowest initial ping time isn’t a “stupid” thing to do – it’s just something based on an assumption that a developer would make that a network engineer would know wouldn’t hold true.

Conversely, network engineers may design systems not realizing the needs of the application. For example:

9. If one stream between you and me can get through, so can another one.

Some applications open multiple connections – one for data and another for control – between two systems for communications. The problem is that middleboxes such as NATs and firewalls block certain ports and may not allow more than one connection. That's why applications such as File Transfer Protocol (FTP) and the Real-time Transfer Protocol (RTP) don't always work, Thaler says.

At any rate, the movie wasn’t called “Ghostbuster.” Work as a team.

Welcome Slashdot and Stumbleupon readers. 

The recent article interviewing Tim Lee is getting some play, so we thought that it would be a good time to go and compile some of our previous coverage of the Network Neutrality issue. 

• January 4, 2007: Network Neutrality Debate: An Introduction and Discussion
• January 7, 2007: Clarification: A Case for Non-Neutrality
• January 8, 2007: Network Neutrality Debate: A case for Net Neutrality
• January 9, 2007: Net Neutrality: Professor Yoo Responds to Comments
• January 9, 2007: Net Neutrality: Conclusions
• October 25, 2007: Traffic Shaping and Net Neutrality: Good Versus Evil
• April 4, 2008: Canadian Bell’s throttling raises uncomfortable neutrality questions
• May 6, 2008: The Morality of Neutrality: Philosophy with Richard Stallman
• August 15, 2008: You down with FCC? Yeah, you know me.
• November 19, 2008: Network Neutrality without regulation? Interview with Tim Lee.

Part 7 in a series adapted from Joel Trammell’s Keynote Speech at NetQoS Symposium 2008

Think back three years ago. Back then, how many of you had an MPLS environment?

The carriers have been busy. And in that MPLS environment you lose visibility.

So how do you quantify how the performance has changed and how that carrier network is performing? After all, carriers claimed that by going to MPLS you would get better performance. But since they don't really monitor their own networks, how would they know? With MPLS, you don’t have a lot of data to validate whether it has improved performance. The ability to quantify how that carrier network is performing is critically important.

Additionally, how do you gain traffic visibility into the traffic flows, such as voice, that can now, instead of being in a traditional hub and spoke design, go from any location to any other location? The ability to understand the traffic flows without having to put devices out at each of your local sites to get visibility back into that traffic is crucial.

Finally, anomaly detection is important because often we see with MPLS routing changes that “just occur” that often affect performance. Suddenly the route changes on a major protocol, unknown to you, and suddenly performance is dramatically affected. So, you'll detect that in response time but you'll also see it in changes in traffic flows that will show up in anomaly detection.

By and large, the argument over network neutrality tends to be dominated by two specific groups, says Tim Lee. Those coming from a technical background who talk about the important nature of the Internet’s open end-to-end principles, or those from an economic background who talk about how non-neutrality makes business sense.

Lee, a frequent contributor to Ars Technica and Techdirt, has recently written “The Durable Internet,” a paper published by the libertarian-leaning CATO institute. In it, Lee argues that both sides miss a key point – that is, the Internet’s open-ended architecture is not likely to vanish, despite the fears of net neutrality proponents, and despite the wishes of net neutrality opponents. For that reason, perhaps network neutrality legislation isn’t necessary – or even desirable from an open-networks perspective.

In “The Durable Internet,” Lee addresses the concerns in “plain English” but with enough technical detail to argue the point for someone familiar with the makeup of the Internet and familiar with the technical issues involved.

We sat down for a phone call interview with Lee, and you can find the podcast here, with a transcription below the fold.

Interview with Tim Lee, 10.9MB MP3

Continue reading "Network Neutrality without regulation? Interview with Tim Lee." »

Part 6 in a series adapted from Joel Trammell’s Keynote Speech at NetQoS Symposium 2008

How many of you out there are doing a server virtualization project?

More specifically, how many of you are doing a server virtualization project that you know of? Because often in companies, the server group will start consolidating servers in virtual servers – and neglect to tell the networking group. Worse still, when a problem develops, the network, not virtualization, gets the blame first.

There’s also desktop virtualization. If you haven't heard of that, that's the idea that, well, a user doesn't really need a machine. What they really need is an image and that image can be pulled down across the network to any piece of hardware that they might be operating on at that given period of time.

Because we all know there's this ubiquitous and highly performing network everywhere in the world for this user to access this image, right? And even though that may be a Windows image that has hundreds of megabytes of data, we're just going to zip that right down onto their local hardware of whatever type it is. Doesn't even matter what type because we virtualized it and we're going to run our desktop locally.

While most of the readers of this blog clearly caught the sarcasm in the previous paragraph, to a CIO, that’s a very attractive pitch. I can promise you there's a lot of venture money being put right now behind companies doing desktop virtualization because nobody wants to miss the next VMware from a returns prospective. So, it's coming. Whether it's a good idea or not, in what environments it works well, that's a whole different question.

Some applications are going to perform fine under virtualization. However, there's a whole other class of applications that don't work well in virtualized environments. Virtualization is not like having another server ‑ it's like having part of another server. And that part, depending on the application, may be good or bad.

So, with virtualization, it's going to be very important that you have the ability to compare performance in the virtual environment with the non‑virtual environment. You want to get in there and get a baseline before they do any virtualization so when they come back to you and say “oh, things have gone to Hell in a hand basket”. It must be the network' you can say, 'no, guys, look, nothing changed with the network ‑ here's the response time on the server you were getting before you virtualized, here's the response time you're getting now on the server. That's your problem. Virtualization caused your problem.

You'll be able to understand better what applications work well under virtualization, because tracking server response time before and after virtualization is the ultimate test. If I virtualized an application and server response time with the load stayed the same, that's a good application for virtualization. If I virtualized an application and server response time goes up by a factor of ten with the same load, I didn't get anything for my money, right? That's not a good application to virtualize. I promise you a lot of server folks are not thinking of this and you're going to be the brunt of dealing with the problem when it occurs.

Then, of course, there's servers running out of resources because now it no longer makes sense to look at the server as a single hardware running a single OS.

So, in that case response time's going to drive the ability. In this case server response time is going to be really critical in you helping prove that this is not your problem. And then from there, device statistics are going to be important as you virtualize servers.

By Brian Boyko
Age 29

I’ve just come back from vacation. I’ve been in New Zealand for the past two weeks. (Did you miss me? I missed you.) Anyway, after the stress of the U.S. elections, (I am a political animal*) I needed it, badly. 

I headed to New Zealand, mostly because I’m obsessed with the country’s multi-party electoral system of proportional representation.  This is especially important in New Zealand, where voting for the “lesser of two evils” invariably means casting a ballot for Saruman.  Also, I really, really wanted to try Zorbing.

Zorbing is basically crawling into a giant, air-cushioned hamster ball, and being rolled down a hill.  It’s just like being in an XKCD comic!

Here’s some pictures and video:

Inside the Zorb from Brian Boyko on Vimeo.

But, of course, as the adrenaline wore off and I reflected on the experience, I realized that, despite all the fun, I would have to start back at work today, so I did what I always do in these situations: Take something totally unrelated to network performance, and relate it to network performance.

For example, the Zorb in Rotorua has two tracks, both of which start from the same point, and both of which come to a stop at the bottom of the same hill; but I only had the time to go down one before the last bus of the day left.  Wanting to extend my fun as long as possible, instead of choosing the straight, downhill, fast track, I chose the bumpy, zig-zag one.  This track was more circuitous and involved multiple hops.  More hops = longer time.  In a network context, this delay is called “serialization delay.” In a zorb, this delay is called “WHEEEEEEEEEEE!”

Okay, it’s a lame comparison, but give me a second to get up to speed – I just got home after traveling for 34 straight hours, including 16 hours of layover and 18 hours of flight. 

The other thing about New Zealand is that everyone there complained about the speed of Internet access – there’s really nothing to do about it, as New Zealand is extremely remote to the rest of the world.  Even Australia is 1,000 miles away, and the alternatives to undersea cabling is satellite communication.  There are bound to be latency issues due to propagation (speed-of-light) delay.

Anyway, I’m tanned, rested, and ready.  We’ll finish up Joel’s series and post some other stuff in the following days.  Thanks for sticking with us. 

* some sort of flightless bird, most probably.

Part 5 in a series adapted from Joel Trammell’s Keynote Speech at NetQoS Symposium 2008

One of the big downsides to WAN Optimization is that you’re breaking up the TCP session that used to be from one end of the network to the other into three independent TCP sessions.

To measure the response time after WAN optimization is deployed, NetQoS worked with Cisco to develop code that exists on every Cisco WAN optimization device that ships. That solved the problem – at least for Cisco WAAS users.

But if I can generalize, you talk to a WAN optimization vendor and they will tell you, "Well, who cares about breaking up the TCP session because we're going to make your network so good you're not going to have to deal with performance problems."

That’s not reality. They will solve a certain set of performance problems, to be sure, but in some cases they may exacerbate problems.

For example, earlier this year, I recall that a Riverbed box had serious issues around AutoCAD. When AutoCAD changed the file format version, the WAN optimization implementation was actually slowing down AutoCAD. That’s an important area that people don't necessarily think about when they deploy WAN optimization: Did it actually do any good and how can you quantify how much good it did?

You have to do some pretty sophisticated analysis to understand what applications are going to benefit from WAN optimization, or any other technology addition for that matter, and which aren't. It's not always obvious how much data reduction occurred. That's one of the big selling points, right? You're not going to have to transfer all this volume across the network; well can you quantify how much data reduction occurred on the network?

Finally you want to be careful what applications may break when they're optimized. So, with WAN optimization the network performance metrics you’ll want to see are response time and traffic flows. That ability to understand and “re-put together” the three response time segments that were broken by putting in WAN optimization in the first place.

[Ed. Note: 17 November - In our comments section, Bob Gilbert from Riverbed points out that the AutoCAD problem has been addressed with a patch from Autodesk, and that the problem with AutoCAD's .dwg files were not Riverbed exclusive.]