My day job is covering networking innovations and trends, but I moonlight as a video editor, director, and producer, so I was personally really excited to hear what Cisco was doing with the Cisco regarding the new Cisco Media Experience Engine (MXE) 3000, and my question lists includes questions about bitrate, framerate, dynamic re-encoding, and “can I borrow one for the weekend, pretty pretty please?”

Network World has a picture of it, which looks like a 1U blade with a DVD-ROM drive. According to the Cisco FAQ, it’s designed to be used in the data center.

But what does it do, exactly, and how will it impact network performance?

Ultimately, the MXE is a transcoding device that resides in the Data Center. For non-video geeks, transcoding is what happens when you take a video that is in one computer format, and want to turn it into another video format. For example, when you take your digital camcorder’s DV tape and burn it to a DVD, part of that process is your computer converting from the DV format to the format used in DVDs – MPEG2. That conversion is called transcoding – moving from one codec to another.

The question, of course, I would have really liked to ask Cisco: What is the advantage of putting the transcoding software and appliances in the data center, compared to, say, buying a Mac XServe, putting it in a closet somewhere, enabling a remote desktop, and using a program like Final Cut Studio’s Compressor to accomplish many of the same pre-processing and encoding tasks that the MXE can accomplish?

This is an especially important question because while one of the key goals of the MXE is to limit traffic congestion on the WAN by reducing large videos into smaller ones. For example, videos may be recorded using an HD camera in HDV, which records at 25 mbits/s in the MPEG2 codec. However, you could save on bandwidth by reducing the movie from the original 25Mbits/s to around 3Mbits/s in the H.264 codec, which preserves video quality at lower file sizes with the tradeoff being the extra processing power needed to both encode and decode the image. You could cut that down even further if you don’t need HD detail.

So, yes, if having an MXE means that raw video travels on the high-bandwidth, low-latency LAN down to the MXE, where it is converted to a smaller file for travel on the low-bandwidth, high-latency WAN, it could be huge.

What seems to be strange, though, is that Cisco suggests, in the online promotional video for the product, sending the large source video through the WAN to be transcoded. I’m not sure that that would work out as well as Cisco thinks it will. Even with a device like the MXE, keeping track of your network’s capacity and monitoring your traffic flows and response times end-to-end remains important for the simple reason that not all video is optimized for the network. We were unable to, as of press time; hear back from Cisco directly, and that was a little disappointing.

So what is the advantage of the design decision to put this in the data center? I’m sure there is one – I just wasn’t able to get with Cisco – yet- to find out exactly what it is.

Additionally, the MXE transcodes files, not streams. This means that video-over-IP won’t be affected by the device. What I’d really like to see is a device that can transcode streaming video on the fly – using higher resolutions and bitrates when the link is relatively uncongested, and reducing it when there is other traffic on the network with higher QoS priority. That would be a killer app for videoconferencing, and this might be a good first step towards that goal.

Readers of this blog will remember “The Strange Case of Julie Amero,” which we’ve covered extensively here:

• Introduction
  
• Commentary by defense expert Herb Horner
  
• Quick info from CEO of forensic software
  
• Commentary by Prosecution Expert Det. Mark Lounsbury
  
• Conclusions

Julie Amero’s conviction was overturned after the Internet community, led by Alex Eckleberry of Sunbelt Software, rallied around her cause.  It’s rare for a judge to throw out a case after a conviction, but the evidence was overwhelming.  A new trial was ordered.

You could have argued that the prosecutors in this case were computer illiterate, but for months, prosecutors held the threat of a new trial over Ms. Amero’s head, and then, instead of dropping the charges, to suggest a plea bargain - $100 fine, loss of state teaching license, and a conviction for disorderly conduct. 

Ms. Amero took the plea bargain, and with the case concluded, she finally was able to speak out in an interview with ComputerWorld.  Here’s a bit of information that we didn’t know:

What was on the screen?
Little itty bitty tiny pictures of sites: Viagra sites, sex enhancement creams, women in lingerie, things of that sort. Nothing lewd.
So no pornography?
No.
Was there nudity?
There was no nudity. There were sites listed. And the things they said [in court] I clicked on and went and looked at have been proven that they never were clicked on and looked at. The things that were on there were just inappropriate things to be looked at in a classroom; Victoria's Secret kind of stuff, you know….

So there was never anything pornographic?
[The prosecution] said there was one site visited, where there was a thumb-sized picture of oral sex.
So they found one picture of oral sex on the computer, but you didn't see that?
No.

The prosecution in this case knew full well that Ms. Amero was completely innocent.  And had an opportunity to try to mitigate the damage by dropping the charges when the wrongful conviction was overturned after the evidence came to light.  They did not.  And eventually they got what they wanted – some sort of conviction of an innocent woman for a crime that turned out never to have happened.

From Rick Green at the Hartford Courant:

New London County State's Attorney Michael Regan told me late Friday the state remained convinced Amero was guilty and was prepared to again go to trial.

"I have no regrets. Things took a course that was unplanned. Unfortunately the computer wasn't examined properly by the Norwich police," Regan said.

"For some reason this case caught the media's attention,'' Regan said.

The good news is that though it may not have resolved satisfactorily, at least it is finally resolved.

President-Elect Barack Obama, recently put a new video on Change.gov, the official Web site of the office of the President-Elect. In the video, Obama is seated in the office of the President-Elect, sitting in the chair of the President-Elect in front of the desk of the President-Elect. And if I had to guess, he’s probably reading prepared notes from the teleprompter of the President-Elect into the YouTube camera of the President-Elect.

These YouTube videos aspire to function much like an online, 21^st century version of the FDR’s “Fireside Chats.” Coincidentally – or perhaps not - Roosevelt’s first Fireside chat, broadcast in 1933, was entitled, On the Bank Crisis. This was also the subject of Obama’s broadcast. And like FDR, Obama is proposing a federal employment program much like Roosevelt’s New Deal.

During the New Deal, the Civilian Conversation Corps, or CCC, was a work-relief program designed to keep people employed with a semi-steady paycheck. One of the main ways that the CCC employed young Americans was by putting them to work solving the environmental problems of that era – which mainly involved flood prevention, soil erosion prevention, wildland fire suppression, reforestation, et al. You can go to Wikipedia for the full details.

Similarly, Obama’s plan, (or the sketches of it outlined in the short YouTube video), calls for increased energy efficiency in national infrastructure. Obama didn’t mention it specifically, but it’s not a far guess to think that part of this process will be “greening” Federal IT – and that usually means server consolidation (perhaps aided with WAN Optimization) and virtualization – to do more with less of a power draw – as well as putting the network to new uses, such as teleconferencing instead of spending money on airfare. Both of these will require network monitoring and adept management.

What Obama did specifically mention:

“It is unacceptable that the United States ranks 15^th in the world in broadband adoption.”

Hmm. Sounds familiar. Sounds like something we’d say. (Mr. President-Elect, are you subscribed to our RSS feed?)

The CCC, and similar program WPA, also focused on building and improving the infrastructure of the country – broadband improvements, of course, are improving digital infrastructure. (Of note – American broadband improvements must be done on American soil, and can therefore be almost “outsource-proof.”)

Also of interest was Obama’s pledge that:

“In addition to connecting our libraries and schools to the internet, we must also ensure that our hospitals are connected to each other through the internet. That is why the economic recovery plan I’m proposing will help modernize our health care system – and that won’t just save jobs, it will save lives. We will make sure that every doctor’s office and hospital in this country is using cutting edge technology and electronic medical records so that we can cut red tape, prevent medical mistakes, and help save billions of dollars each year.”

We at NetQoS have a little bit of familiarity with how difficult medical networking needs can be. In Volume 3 of Performance Edge Journal, we published a case study of OSF Healthcare, which is a network of multiple acute care, long-term care, and college of nursing facilities and also a primary care physician network.

One of the applications that OSF wanted to implement included Picture Archival and Communications System (PACS) – in order to send and manage very large cardiac images. The application had very slow response times, and you know, when something’s wrong with your ticker, time’s of the essence.

Anyway, NetQoS considers this one of our big success stories. Through SuperAgent, they found that the delay was caused by excessive server response times, and using ReporterAnalyzer, they were able to figure out that some cardiac images were being sent to different sites across the WAN and not stored locally, slowing down retrieval times considerably, taking up large amounts of bandwidth unnecessarily.

Whether or not Obama’s plan will actually work, at least he seems to be aware of the real need for network performance in the healthcare industry.

At the risk of waxing political; Obama talking about technology policy means that the next four years (at least) will be interesting times for geeks. Under the Clinton and Bush administrations, discussions of what should be done about networking issues were mostly confined to – well, to blogs like this. (And even then, it was mostly confined to Slashdot). But, whether or not you agree with him, Obama seems to be using the power of his office – or of his future office – to call attention to the problems that up to now, only us techies were paying attention to.

By Chandra Hosek

At one time or other, network engineers have channeled Rodney Dangerfield, and exclaimed, “I don’t get no respect.” It seems like the network is blamed first for most every IT issue.

Does the perception of the network as just a set of dumb pipes – the plumbing of the IT world, as it were – make network engineers in people’s minds just “the plumbers?”

Now, plumbing is an honorable profession (and when you need one, you really need one), but the comparison does network professionals a disservice. It may have been apt when a network professional’s main focus in life was keeping all the network devices up and running, but that’s no longer the case. And it perpetuates the fallacy that the network is just a utility: You turn it on like water or electricity and it always works the same barring a major problem.

It doesn’t work like that. Today’s networks are dynamic, complex entities that are ever-changing. Managing them is made more challenging by a push-pull effect of end users and branch offices spread further out in far flung locations while resources are being consolidated in a few data centers and other central sites. Other trends such as virtualization, WAN optimization, cloud computing, and others make network management anything but trivial.

As a result, the network professional today is responsible for much more than “the pipes and fixtures.” Ensuring the delivery of critical applications over the wide area network has become the responsibility of the network engineer, and it is performance, not piping, that is the major concern.

With that in mind, we posit a new, more accurate alter ego for the network engineer: The doctor. A cross between a primary care physician responsible for preventative care and a cardiologist responsible for ensuring the circulatory system is performing adequately.

The network is the lifeline of the business, requiring skilled engineers to constantly monitor and manage the performance of the applications traversing the major arteries.

Especially in today’s economy, it’s in the network engineer’s best interest to show that he or she has moved beyond just watching red and green lights looking for device problems that now only happen less than 1 percent of the time. (A doctor doesn’t hang around the on-call room only getting off his butt when someone flatlines.) Heck, you can outsource that function quicker than you can say “plumber’s crack.” It’s time network engineers get more respect for the work they do. The health of most businesses depends on realizing how critical the network is and focusing on performance, not just availability.

Help us out: What more could NetQoS be doing to educate people? What should network engineers be doing to educate their management and others? Feel free to leave a comment below.

Chandra Hosek is Senior Public/Press Relations Manager at NetQoS.

By David Oliver

We did have the opportunity to do this blog post as a video recording and put it on YouTube, but we realized that, ironically, as the post is all about how companies use NetFlow to track YouTube, because YouTube can, in many cases, suck down bandwidth, it was probably best just to write this out in text.

As we mentioned a week ago, YouTube is now supporting high definition content, with a high bandwidth to match.  Now, I've done a little bit of research into how YouTube actually works.   So I thought I’d explain to all those companies out who don’t yet have their own solutions some ideas about how to track and manage YouTube and other streaming media data – as well as give users out there an idea of exactly how companies can track your YouTube usage at work. 

Anyway, when you make a request for a video on YouTube, you are directed to YouTube’s servers via one of four IP addresses that are easily found on Google or other search engines.  From there you're going to be relayed to the Limelight network, which will actually feed you the video in the flash-based player.  You can see the flows to and from that initial IP address for the HTTP GET of that video. 

There are many solutions for providing visibility into traffic on the network by looking at the Cisco NetFlow data (which is already on most Cisco routers).  I’m going to refer to NetQoS’s own solution,  ReporterAnalyzer, when I talk about tracking NetFlow data. 

What we can do with ReporterAnalyzer is monitor the Internet-facing link, and create and use custom reports looking for YouTube’s specific IP addresses.  If you see a substantial amount of data being transferred,  that's a good marker of seeing that YouTube video traffic. 

You can rely on those custom reports and run them anytime you want, but companies can also monitor YouTube in real-time.  By mapping HTTP Port 80 traffic that involves one of YouTube's IP addresses to some other ephemeral port, (and naming it something catchy, like "YouTube,") it'll actually show up as it's own protocol in both real time reporting, as well as flow forensics.    You could use that data to create customer reports, to get a comprehensive list of users, and to sort YouTube use by volume. 

The other thing you can do is use analyses to know when YouTube traffic accounts for more than, say, 10% of any of my links' traffic.  Then it will go through on a link-by-link basis and tell you about violations, helping you further localize the source of that traffic. You can also configure it to alert you when and only when YouTube traffic on a particular link passes a threshold that you set. 

(The other option is to try to block it entirely, but that's an engineering nightmare.  Any employee smart enough to provide good value to a company - particularly a high tech company - will likely be smart enough to know how to circumvent blocks through proxies and other means.)

Custom reports to find correct addresses and to localize YouTube traffic may take a couple minutes.  The entire real-time application mapping process takes maybe another 15 minutes.  I can be showing real-time data specific to YouTube traffic just a few minutes after configuration of application mapping.  (If your boss asks in the morning for something to track YouTube usage, the company can get YouTube tracking up and running by that afternoon - if the boss just wants some a quick snapshot of the current YouTube traffic volume, it could take as little as five minutes through custom reports.)

Of course, this isn't limited to YouTube.  You can use similar methods and techniques to find and track streaming audio feeds, other video sites, etc. Any TCP flow is going to create some sort of NetFlow data.  Based on the source or destination address, you can localize that.  So as long as ReporterAnalyzer has visibility of that destination address, they can report on it.  As you know, there are a multitude of media based streaming sites, all of which are going to have their own IP address range, which you can find pretty easily.  You can then further localize and label them so that when you pull up reports, they're already differentiated from other traffic.

While YouTube is great, we’ve found that YouTube traffic congesting corporate networks is a common issue. For any company, WAN links are a finite resource and need to be managed.  It's something that's a concern because you're sizing your network around capacity needs for the business.  YouTube is (usually) non-business traffic, but it's going to share that limited resource.  The more you share a resource, the less is available for the requirements you originally scoped it for.  At NetQoS, we’ve found YouTube traffic congesting corporate networks is a common issue.

A column in The Register claims, amongst much wailing and gnashing of teeth, that implementation of BitTorrent-over-UDP (dubbed uTP) in the new alpha version of uTorrent, one of the official BitTorrent client applications, will end the Internet as we know it and completely congest the network.  The title is “Bittorrent declares war on VoIP, gamers.”

Considering the fact that BitTorrent, Inc., has, if anything, always gone out of it’s way to avoid declaring war on anybody, this seemed to me a little bit odd.

I’ll admit that it kind of worried me – TCP has traffic congestion management built into the protocol, UDP does not.  When UDP and TCP exist on the same network (for example, when rolling out VoIP on a corporate network), QoS policies are needed to keep UDP from taking up all the bandwidth while TCP meekly  throttles back.   Jim McQuaid has a Whiteboard series video up about it, and called it “Nice Guys Finish Last.”

The reason that UDP is popular is that it’s a lightweight protocol that doesn’t do much handshaking.  It sends the data “that-a-way” and doesn’t particularly care if it makes it.  That makes it perfect for VoIP, gaming, and other Internet protocols where latency is more important than throughput.  TCP, with congestion control and packet confirmation built in, sacrifices latency for accuracy.  A dropped packet in a phone conversation isn’t much to worry about, but a half-second delay is extremely annoying.  On the other hand, a half-second delay in downloading a computer program isn’t much to worry about, but a dropped packet means that the program won’t run. 

So, as a general rule, TCP runs data apps, while UDP runs real-time apps.  Rudimentary QoS policies based on giving UDP packets higher priority may not be perfect, but they can be a good start to improving performance on simpler networks. 

My concern was that putting BitTorrent, a non-latency sensitive application – on UDP would result in it receiving higher priority traffic.  But after speaking to Simon Morris, the Vice President of Product Management at BitTorrent, Inc., I was assured that this wasn’t the case. Morris explained:

[Editor's Note: Some words got a little garbled in the phone conversation I had with Simon Morris, and he sent me an e-mail with clarifications. I've made corrections via strikethroughs. --ed.]

“BitTorrent obviously needs to be a accuracy-sensitive protocol but we believe it needs to also be …MORE sensitive to latency than TCP, not less sensitive.

This is to say that with uTP, we have taken UDP, implemented a layer of reliability and spent a great deal of time implementing a congestion control mechanism that is better than the one used in TCP (better = faster to detect issues, faster to react).

It’s not QoS, but rather a congestion management mechanism implemented at the end-user’s layer 7 [Application]. This will stop uTP from eating up traffic bandwidth reserved for latency sensitive apps like VoIP and gaming. What’s more, the congestion management mechanism isn’t something we implemented as an afterthought – it’s the whole point of uTP.

In short, it seems that rather than using UDP as a way of getting around TCP’s traffic congestion features, the new protocol is rebuilding better traffic congestion features at layer 7, using the lightweight UDP protocol as a simple base.  In short, to mangle a metaphor, they’re re-inventing a better wheel. 

If uTP does congestion control for BitTorrent as an application, this could provide an answer to BitTorrent critics, and ISPs who claim that BT throttling is necessary because it’s “eating up bandwidth.” I asked how uTP implemented congestion control at Layer 7 [Application] rather than Layer 4 [Transport].

Morris: “So basically, what TCP does is that it stops detects congestion only when it detects packet loss and then it throttles back.  Because we control both ends of the transfer, we can actually measure the single-trip time between when the packet is sent and a packet arrives.  (Not round-trip-times but single-trip-times…)  We have essentially, an ability to monitor single trips over the internet across millions and millions of terminals, and we built an algorithm around that to do things like eliminate the discrepancy between the stock clocksettings on different terminals - to identify where there is actual - very fine grain, down to milliseconds - changes in the speed of which packets are arriving….” 

“The way that prioritization policies are set [by network operators] is extremely varied, and so, it's possible that [uTP-based] BitTorrent traffic will get a higher prioritization, but only in cases where it's not causing any type of congestion at all… [uTP] will never trample over UDP based latency sensitive traffic, nor TCP-based traffic.  [UDP is] designed to throttle back if there's anything else on the line. 

“I mean, it's essentially designed to be - a term that we use internally is - a "scavenger protocol."  It scavanges and uses bandwidth that is not being used by other applications at all, and it's designed to throttle back very very quickly in case there is any type of congestion on the line.

“Unfortunately the way that TCP works is - just profoundly broken as a method of control congestion on the Internet.  Especially when there are applications out there that are designed to get the most out of network bandwidth - like BitTorrent.  People have tried to make TCP better, but the problem is that it's such a huge implementation task to make it happen, because you need to upgrade all of the Web servers and all of the terminals.  Now, the insight here is that in most manycases, we have control of both ends of the [communication].  So we can actually take the right steps in the direction of solving this problem. 

Those concerned about BitTorrent (either classic or newfangled) traffic on their networks might want to check out a solution designed to monitor and track the types of traffic going on the network, including information about what applications are transmitting and receiving what amounts of traffic. 

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.