Commentary Archives

VoIP eBook Excerpts: Critical Elements of Your VoIP Infrastructure


Over the next week on Network Performance Daily, we’ll excerpt sections of the new NetQoS VoIP ebook entitled VoIP: Do You See What I’m Saying. Today, we take a look at the hardware needed to equip your VoIP infrastructure. Obviously, VoIP systems don’t just require some server configuration and special software. Quite frankly, you can’t plug an RJ-10 phone line into an RJ-45 ethernet port and say you’ve got VoIP.

(We all know someone who might actually do that. If you’re lucky, he or she is not in your IT department…)

So, what is some of the VoIP hardware you need?

First, in terms of sheer numbers, IP phones will make up the largest group of new devices on your network. These IP phones connect to the network via Ethernet and many of them get power-over-Ethernet (POE) from LAN switches that support it. Each of these phones runs an embedded operating system with a TCP/IP stack for communications, which means each phone needs its own IP, and software called a codec to convert a voice conversation to IP packets.

Depending on how fancy your phone is, many of these phones can also run applications. Additionally, there are also “soft” phones – basically headsets that connect to the computer and an application which runs on it.

Continue reading "VoIP eBook Excerpts: Critical Elements of Your VoIP Infrastructure" »


Commentary Archives

Welcome to the Data Center, Here's your Parka.


There's a story in the newly free-for-online-viewing Wall Street Journal about how companies expanding globally often use multiple headquarters, leaving their original headquarters locations behind in an effort to become "global brands." For example, Lenovo is a Chinese company - but they've got headquarters in Singapore and Raleigh.

Companies have varied reasons for moving beyond the nest. Some, like UniCredit or Lenovo, found their businesses and work forces reshaped after cross-border mergers or acquisitions. Others, like consultancy Accenture Ltd., which has no headquarters and whose CEO has no office, are reflecting their far-flung customers.

Obviously, distributed companies require distributed networks; Wide Area Networks obviously play a big part in getting each of the “world headquarters” of these companies the information that they need in a timely fashion, and it is only getting bigger.

But that got me to thinking - if you can have headquarters anywhere in the world - why couldn't you have a datacenter anywhere in the world, separate from the headquarters?

Continue reading "Welcome to the Data Center, Here's your Parka." »


Commentary Archives

High-power consumption could be confused with pot growing


brianboyko3.jpgBy Brian Boyko
Editor, Network Performance Daily

The Austin Chronicle - Austin's local alternative weekly newspaper - reported today that police busted a pot-growing operation in a rental property based on "data-mining" that they did using Austin Energy's customer database.

Colby's lawyer, David Dudley, argues that APD Detective Jeff Haynes used energy-consumption information from thousands of Austin Energy customers - without those customers' knowledge or consent - in an effort to find and focus upon AE customers who, in Haynes' opinion, regularly consume more kilowatt-hours than he believed "typical" for the size of their residence. In other words, rather than developing an investigation and then accessing a discrete and particular set of energy-consumption data in order to verify other evidence that suggests a growing operation might be under way inside a particular house, Haynes was working with AE, and in particular with business process analyst Mark Coffey, to troll through thousands of records from across Austin in an effort to find energy-consumption "targets" to pursue.
AE officials insist their cooperation with APD is required of the city utility - pursuant to a 1994 ruling from the Texas attorney general's office and supported by federal legal precedent.

Continue reading "High-power consumption could be confused with pot growing" »


Commentary Archives

Advance the cause for network performance. Vote for Joel!


Joel Trammell is the CEO of NetQoS, an Ernst & Young Entrepreneur of the Year award winner, and now, he's a nominee for Inc. Magazine's "Entrepreneur of the Year."

I don't know much about business and investing - if I did, I wouldn't have majored in liberal arts - but he anticipated the demand for network monitoring software to keep voice, video, and data traffic under control, he keeps the company profitable and we seem to have closed some major deals with companies like Cisco and Network Instruments, which, y'know, is kinda great.

So, yeah, I think he deserves it.

You can vote on the article to register your support for Joel. Now, as the company's resident New Media strategist, I was tasked with creating the response to this development. I patiently explained what the proper internet decorum is for such things, clearly established through a decade of internet precedent and the latest ethics discussions on the nature of new media.

The only fit and proper thing to do is to use the power of blogging to get as many people to vote the way you'd like as possible - even if they may not know anything about the subject in question.

So go ahead and vote early, vote often.

Pretend he's Ron Paul.


Commentary Archives

Tales... from the NOC Keeper


thenockeeper.jpgGood Evening, Network EnginSNEERS and System DEFENESTRATORS! It is I, The NOC Keeper, with a tale of ghoulish fright.

So keep on reading this Web BLARGH, and be prepared for

NETWORK HORROR STORIES!

Bill Alderson:

(This story is lightly embellished.)

An organization long ago experienced a problem with a server mysteriously in the middle of the night at about the same time. After much ado, an investigation was launched and two candidates were chosen (drew the short straws) to spend the night in the “troubled facility” one Halloween.

Alas, about the time expected the two huddled technologists noticed a beam of light mysteriously approaching. Soon they heard steps and an old man with a deep scratchy voice coughing. Both technologists now standing in a “puddle of p*** with snot bubbles blowing from their noses” heard a loud clank come from the area of the server.

Scared to death, they called out with a scream, leaping toward the night watchman as he turned grabbing his chest noticing the pair wide eyed in the corner of the office.

The watchman placed his huge magnetic flashlight each night on a metal case in the office allowing him to focus the light beam down the long cubical area as he made his appointed rounds. The watchman had no idea it was the departmental server he was disturbing each night.

Loyde Hales:

(This is a true story, delivered first-hand by the seaman involved.)

Serving on a USNS aircraft carrier as the senior computer/network specialist, our Heroic Seaman was regularly called to one of the operations centers to fix an errant piece of hardware. As the case happened, this particular equipment had the tendency to “cautiously predict a problem,” causing failover to less sophisticated systems. No, it was not designed by a large company in Redmond, Washington. After the couple of failures, our Heroic Seaman detected a pattern, which he promptly recorded in the logs for future evaluation. Any time he reported to “repair” the equipment, he made a point to explain to the department’s watch what had happened and the very simple way to fix it.

Weeks go by, and he’s still getting regular calls at all hours for the same issue. One late night, he decides to at least enjoy being called from his bunk. Grabbing some accouterments to aid in his “debugging”, chiefly in the form of bells and feathers, he proceeds to do a “voodoo dance” (his words) around the equipment in the room. In one of the passes of the room, he surreptitiously touched the reset button, causing the system to check its state and resume primary function. He then remarks that “that should do it” and nonchalantly leaves.

The Navy, however, was not amused. By afternoon, he found himself before the Brass to have explained loudly
that the Navy would not have a voodoo dance in the log or the resolution report, and he’d better amend his position immediately.

Jim Duster:

My first high tech company in Austin was ITMasters, and we were officed out of very small rental offices on Pond Springs road. We had to keep two oscillating floor fans going in the server room to keep the servers cooled. You had to be careful not to plug the coffee pot AND the microwave into the same socket as the HP server. Brownouts were normal. One day, 4pm, sun in the sky, we had a complete all lights out dark episode. The whole building went off the electrical grid. We found out it was caused by a squirrel who had climbed the telephone pole outside the server room and stretched a long stretch between the hi-line wire and the actual transformer coupler. One of our programmers described it as “first you saw this huge blue arc, then you saw the squirrel going one way and his tail going the other way”. Took us several hours to get power restored.


Commentary Archives

HTTP, the Once And Future King


Not that I'm in the loop or anything, but NBC and Fox's parent companies have banded together to create an on-demand television show streaming video site. They called it Hulu.com, (which just goes to show you that all the good domain names are already taken.)

It's a YouTube competitor with one thing going for it: Legal viewings of NBC and Fox shows. And that may be grand and glorious, but I remember back in the 1990s when every record label put out a separate music download service - and were trumped by iTunes which sold records from all the labels. But I digress.

The point is, if even the major networks are saying that it's time to start shifting product from the television to the Internet, it means there is a significant trend shift.

And indeed, looking at traffic patterns, there certainly have been. Previously, Peer-to-Peer traffic was considered the number one way that files got moved around on the Internet. But lately, P2P's position as Internet Bandwidth top dog has been replaced by the HTTP protocol - streaming video likely has quite a bit to do with that shift.

There's an article in Ars Technica which shows that HTTP traffic takes up 46% of the Internet - at least from broadband users, while P2P takes up merely 37%, putting it in second place.

This is problematic from a network performance standpoint. Peer to peer traffic does indeed have its place - BitTorrent transfers of Linux CDs and large file versions of Microsoft patches come to mind. But it is easier to identify and not usually as work-critical to segregate that traffic. With the video traffic from YouTube coming in over HTTP, you can't just block off HTTP. You need to be able to figure out the type of data in the payload - not just the protocol of the traffic.

Now, there are business applications of YouTube (we use it quite a bit in our marketing department) and other such bandwidth-heavy hogs, and an outright ban would be counterproductive. So how do you have your YouTube viral marketing campaigns while still maintaining that the business data goes through in a timely manner? The answer is probably to put a QoS policy in place for streaming video, but in order to implement it, you need to have visibility into your data.


Commentary Archives

Spiceworks and the Ad-Blockers


A few weeks ago, we wrote a story that got a significant amount of pickup from several sources called “Ad-Block: Adapt or Die,” where we posited that the technically savvy would – and in some cases even should – use the Ad-Block tool, despite the fact that it is disruptive to the advertising business model.

One of the network management programs out there that we don’t talk about much is the Spiceworks IT Desktop – a SAAS-based network management and general IT organizing tool for small businesses. It’s downloadable for free but supported by advertising.

First let me say that Spiceworks is not competitive to our own products. For starters, they only support networks with 250 devices or less. However, we were privately skeptical, at the time, that this business model would be sustainable. After all, aren’t the same people who work with complex IT problems also the ones most likely to download tools such as Ad-Block? (Which makes me think – can you use Ad Block with Spiceworks?) Aren’t they the ones most annoyed by advertisements and wary of any ad-based revenue model for software? (Most of us tech geeks got hit with Kazaa’s spyware infections back during our late teens, after all.)

And indeed, Spiceworks is now offering a version of the software without ads for a subscription fee. By offering that option, they’ve opened up an alternative form of revenue from technical people who can’t stand to bear ads.
So, to answer a number of questions, I do believe it is possible and viable to adapt away from an advertising-based business model. I think Spiceworks, by offering an ad-based and subscription-based model, is offering the best of both worlds for small businesses.


Commentary Archives

Traffic Shaping and Net Neutrality: Good Versus Evil


brianboyko3.jpgBy Brian Boyko
Editor, Network Performance Daily

The Net Neutrality debate can often be overzealously couched by supporters and detractors of Net Neutrality legislation as an apocalyptic fight between good and evil.

Weirdly, they’re right. But not in the way you think.

See, at the core of Network Neutrality issues are appliances or programs which conduct traffic shaping. In traffic shaping, some packets are prioritized, others are held back. This prioritization can be done on the basis of content (what type of data is being transferred,) on the basis of application (what program is transferring the data) or on the basis of IP address (which computer is sending the packet, and which computer is receiving it.)

gve.png

Now, here’s the rub: Traffic shaping can help improve network performance, decrease latency, and increase bandwidth by delaying those packets deemed to be of a low priority. Sounds good, right?

Not so fast. Traffic shaping can degrade network performance, increase latency, and decrease bandwidth… by the same means.

It all depends on who is controlling the traffic shaping and what packets they choose to prioritize. Traffic shaping, like guns, can be used for good purposes: A gun can be used for family protection, hunting dangerous or delicious animals, and keeping the King of England out of your face. And like guns, traffic shaping can also be used maliciously.

So, yes, Net Neutrality is very much a contest of “good vs. evil.” It’s just that the potential for good or evil depends entirely on who has control over determining what packets get priority, and for what purpose.

(Continued...)

Continue reading "Traffic Shaping and Net Neutrality: Good Versus Evil" »


Commentary Archives

VoIP Notes: Echo Echo In Voice over IP Systems Systems


Echo is a troubling problem. Most of us have suffered through some call where we had to try to talk with a lot of echo on the wire. It’s very distracting and makes it hard for most people to think straight and talk at the same time.

VoIP does not create echo, but due to the temporal aspect of echo, VoIP systems can and do increase the amount of echo heard when talking.

In any conversation, a certain amount of your own voice is part of what you hear, whether you are talking live, sitting in your office, or on the phone. This “hearing your own voice” is not echo and is referred to as “sidetone.” It’s a normal aspect of talking and listening.

Your own voice becomes echo when it comes to your ear with a significant delay from the time you spoke – longer than 25 milliseconds. But 25 to 150 ms is a typical delay range for international calls and this is why echo cancellation is necessary. Voice over IP calls have a delay budget also in the range of 150ms.

So, what causes echo?

First, let’s look at what doesn’t cause echo. Because delay is a necessary condition for echo, it is virtually impossible for components that are close to the speaker, e.g. on the speaker’s site, to cause echo. Even if part of the transmitted signal is being reflected back in the return channel, the propagation delays will be so brief that it will never be heard as echo.

Also, there is no way for the digital stream of packets in one direction to “bleed into” the digital stream of packets in the other direction. The same is true for the digital parts of the PSTN TDM network. While the underlying electrical signals carrying the bits are, indeed, analog, the corruption of those signals results in digital noise or other problems, not in echo.

So, strictly speaking, echo is never caused by voice over IP. In fact, what happens is that the longer delays introduced by all voice over IP systems reveal echo that was imperceptible with the shorter delays of the PSTN. By delaying existing echo signals more, they fall outside that 25ms window and become audible to us.

Echo is always analog and always at the far end of a conversation.

(Continued...)

Continue reading "VoIP Notes: Echo Echo In Voice over IP Systems Systems" »


Commentary Archives

Is Web 2.0 an crisis-in-the-making? Jim Metzler speaks about the impact of Web 2.0 on Network Performance


"In fact, I was talking with someone the other day," said Jim Metzler. "I don't need to be dramatic, but he said to me, 'Jim, I look at Web 2.0 the way I look at global warming. We're just beginning to realize how serious global warming is and take some steps now. We're not there yet on Web 2.0, but it will have a dramatic impact."

We talked a little bit about how broadband is causing end-users to expect more from the Web apps that they use for work, but here's a basic recap: If a user is used to waiting less than 5 seconds for a YouTube video, they may not be as willing to wait 30 seconds for a database. Things are getting faster, and as such there should be a new emphasis on providing performance.

We are used to information in real-time. Our growth of interconnectedness - indeed, the growth of community - has driven us to new expectations.

So we talked to Jim Metzler about whether Web 2.0 is creating new requirements in network performance.

"I think they will once they get more broadly deployed. I actually think that things like SOA and Web Services, Web 2.0, are going to significantly rachet up the need for a more dicisplined performance management, but I don't think people realize it yet…. I think we're still kind of kicking the phrases around. People are saying, 'Oh, Web 2.0, that's all marketing hype, no one knows what that means, yadda yadda yadda' So I think we're still in the denial stage. But I think that, over time, it will have a significant impact on the need for performance management and how we do performance management."

So, what can companies do about Web 2.0?

"I think where's there's SOA Web services, the bottom line is, for starters, we can't chart a course to improve, if we don't know where we're going. It's as simple as that on one level. So we need to continue to educate ourselves as to what exactly Web 2.0 is. And you're not going to be able to get a very precise definition, but you begin to read and see some commonality. 'Is my company heading in that direction? If not Web 2.0, how about these SOA Web services?'"
"I think that on the infrastructure side, to understand the evolving application disciplines, architectures, whatever you want to call it, not, so to speak, just in general but as their company is evolving to it, to figure out what that means for them - Initially it just comes down to guessing at the high level picture and then coming down closer to the ground. As you have some of the monitoring tools that people are deploying, they begin to place more emphasis to understanding the flow of data in an application."
"Becoming more application aware today, not just what applications are running on the network, (that's a good starting point,) but how do they actually transfer data and where are the performance roadblocks? So, it's kind of getting a handle on today while beginning to understand where we're going to evolve to over the next one to five years."

When asked if there was anything else he wanted to mention, Jim Metzler said: "Let's hope the Red Sox can beat the Indians."



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37