This is interesting; I actually had a conversation recently with my boss, in which I argued that the elections may have an impact on network performance so much as who is elected will help determine U.S. telecommunications policy, but otherwise… well, there wasn’t much to write about on the blog.

Apparently, I’m wrong. Because Slashdot just posted “Watching Tonight’s Presidential Debate Online,” and Slashdot is the IT blog. Maybe I made a poor judgment call – especially after hearing from poster ObsessiveMathsFreak:

The US presidential elections are actually very important. I see Slashdotters posting comments to the effect that both parties are equally bad and it doesn't matter which way you vote and excuses, excuses, excuses. I can tell you from the point of view of someone who is very much affected by the results of your national elections, this is a pretty depressing thing to hear. It's clear to anyone who has half a clue that there are very wide and deep differences between the two main candidates, and it's quite irritating to find out just how flippantly many Americans go about voting, or not voting, for their president.

Your election affects me. It affects people around me. My nation's economy, policies, laws, and culture, yes culture, are significantly affected by your selection of a president, through his administration's policies. This is "Stuff That Matters" to me.

The other important thing is that the original submitter prefaced his article “For those of us that no longer have a television…”

This is important because for whatever reason, geeks are early adopters. It’s geeks who first bought GPS devices; now they’re mainstream. It’s geeks who were first on the Internet. Now it’s everyone. It was geeks who first started blogging, geeks who first started eco-driving, geeks who first started “podcasting and vodcasting” before iTunes and YouTube brought it to the masses. And it was geeks who were rolling dice and pretending to slay dragons way before World of Warcraft.

If geeks have learned that they can eschew their televisions completely – not just the cable but the actual box – then where are they getting their audiovisual media from?

And that’s where we get into network performance – because there’s the possibility of hitting that tipping point where most people will be getting their audiovisual content via the Internet.

What’s strange is that this goes back to Clay Shirky’s thesis that we’re moving through a shift where the cognitive surplus created by the move to the forty hour workweek is no longer masked by television – that is, that we now have other things to do with our time. Television is a technology that essentially is designed for the person to sit down and “see what’s on.” Internet video is designed for two types of people: those who know what they want to watch and when they want to watch it, and those who treat video media as any other media, following hyperlinks where they may lead – if it’s text, graphics, audio, or video, so be it, so long as they get the information.

It is not enough to dismiss all video content as “recreational network traffic” because eventually we will start to communicate more and more with multiple media as costs go down and we all become more familiar with producing and sharing. This means that networks have to be able to handle the traffic that video will require.

In the meantime, enjoy the debate – online, or on the air.

I wanted to name this post “Things to view in Denver: Talking heads” but no one around the office got the reference.

Well, if you were worried that Obama’s VP announcement would overwhelm your network, you were spared. The announcement came in the middle of the night – 3 a.m., in fact – on a weekend. But convention season is starting, and that’s a whole additional set of worries.

At 5 p.m. EST today, the Democratic National Convention will begin, and with it, streaming video from multiple news networks and the DNC itself, which, like NBC’s Olympics coverage, uses Silverlight to project a “high-definition” (480p?) image.

Unlike the Olympics however, there’s bound to be some event – a protest that goes wrong, a verbal gaffe, a moving speech – that becomes a viral video. The reason I’m pretty sure about this is that it’s in the interest of both political parties that something goes viral – something good for the Democrats, something embarrassing for the Republicans. Politicians will find a compelling video of an unplanned, sincere, candid, spontaneous moment, even if they have to manufacture one.

There’s bound to be online coverage from the major TV networks as well.

And then after that, the Republican National Convention – with streaming through Ustream.tv - is next week. And McCain is yet to announce his vice presidential nominee.

Those interested in Obama and McCain’s technology policies will find this article at Ars Technica interesting, while C|Net has technology policy information for Biden.

By Kevin Davis
Adapted from “Sources of Latency” Whitepaper

When network users call the Help Desk to report poor application performance, you don’t typically hear things like “The router’s CPU is too busy!,” “The network utilization is above 70%!,” or “The carrier path has failed-over to a sub-optimal path.” Instead, what you’re likely to hear is “The network is slow” or “The calls on my IP phone sound terrible.”

Complaints that end-users lodge are nearly always based their quality of experience using the application. And their quality of experience is almost always reliant on time.

Anytime a significant delay occurs in the delivery of network data, application performance suffers. Depending on the type of application and how it works, variances in network delay can have a severe impact on application performance thereby degrading end-user’s experiences.

Two important measurements of time intervals in network transmission systems are referred to as “latency” and “jitter”. Understanding latency and jitter sources and how their values vary in network architectures is critical to engineering application performance and optimizing information resources. For many regular readers, this will be old-hat, but we’ll go over it again.

Network latency is the amount of time it takes for a packet to be transmitted end-to-end across a network and is composed of five variables:

Network Latency = (Distance Delay) + (Serialization Delay) + (Queue Delay) + (Forwarding Delay) + (Protocol Delay)

Serialization Delay refers to the amount of time it takes for a network interface (such as a router’s interface or computer’s NIC) to perform bitwise transmission of a frame unto the outbound media, Forwarding Delay is the amount of time it takes a network device to process a frame/packet by performing a destination address lookup and forwarding the frame/packet to the outbound interface, and Protocol Delay is the amount of time that access or transmission algorithms may contribute to the delay of a network frame, and is typically introduced at the endpoints of the data transmission system.

Serialization delay, on a per-packet basis, becomes insignificant at data rates above 1.544 Mbits/s – or a T1. Forwarding delay is typically insignificant in modern routers and switches (when appropriately configured – significant delay can occur in misconfigured routers.) And Protocol delay typically occurs at the access layer or the end points. So the two major variables that have the most effect on network latency are Distance Delay and Queue Delay.

Distance Delay is simply the minimum amount of time that it takes the electrical signals that represent bits to travel down the physical wire. Optical cable sends bits at about ~5.5 µs/km, copper cable sends it at ~5.606 µs/km, and satellite sends bits at ~3.3 µs/km. (There are a few additional microseconds of delay from amplifying repeaters in optical cable, but compared to distance, the delay is negligible.)

Distance delay can have a significant impact on application performance for applications that require a large number of network round trips in order to complete a transaction – for example, custom transactional based applications, database queries, and VoIP, which begins do degrade when one-way end-to-end latency exceeds 200-220 milliseconds.

One of the biggest sources of end-user ire are database queries designed to run over a LAN ported to the WAN. For example if a user executes a SQL database query that requests 100 rows of a database table, one row at a time, over a link with a latency due to distance of 60 ms, it would take approximately 6 seconds (60 ms * 100 turns) to complete the transaction. The same query executed by a user on a LAN connected to the same database server would take less than 2-3 ms to be completed, as the latency due to distance across the LAN is insignificant.

Queue Delay is the amount of time a packet must spend in a network buffer waiting its turn to be transmitted. Network interfaces transmit one frame at a time, typically one bit at a time. As such, when two or more packets are forwarded to a network interface at the same time, or close to the same time – one packet is transmitted while the others are put in a queue on the interface buffer to await their turn at the interface. Packets that are put into the queue must wait until they can be transmitted, adding milliseconds of delay.

Increases in Queue Delay can be measured and detected by monitoring traffic along a given network path. Typically, most intermittent increases in latency above the baseline distance latency can be attributed to network congestion. (In order to reduce the possibility of excessive queue delay, application servers that are members of the same application architecture should be placed on the same Ethernet switch and on the same VLAN to ensure they do not have to compete for uplink bandwidth when problems like the one pictured above occur.)

Worse still, if the problem gets worse and packets wait in increasingly longer lines within the queue, the buffer may become full and the packets may be dropped. Packet drop, in turn, causes TCP connections to throttle back on the rate of transmission.

Those are some of the main causes of latency – but what about jitter?

Jitter is a term that refers to the variance in the arrival rate of packets from the same data flow, and abnormal jitter values can negatively impact real-time applications like VoIP and video. Jitter is typically created by three different mechanisms in a network: variance in Serialization Delays due to variance in packet sizes, variance in per-packet Queue Delay due to packet spacing from multiple sources at a common outbound interface, or packets taking different routes from source to destination – perhaps due to per-packet load sharing or routing issues.

The most effective way to deal with jitter is by using low-latency queuing for VoIP and video traffic on network interfaces with large serialization and/or queue delays. In addition, endpoints (such as IP phones) can use jitter buffers or playout delay buffers in order to deliver received packets at a constant rate to the end consumer. These buffers are typically 30-50 ms in depth, and thus they attempt to manage jitter values within these values on any single one-way path. While these buffers technically add 30-50ms in latency, they significantly reduce jitter. Since human beings don’t start to notice latency in VoIP or VideoIP applications till it hits about 200ms, if latency can be kept to under 150 milliseconds, then jitter can be significantly reduced using this method.

There is a site out there - I won't tell you what it is but you can probably find it - that offers every just about every live sports game there is, whether or not the respective television networks have allowed it, whether or not the respective sports league have given express consent for rebroadcast, whether or not the sports game is only televised on Indonesian TV. I'd tell you what the site is, but I think it might be illegal, and besides, it's not like it's hard to find through Google.

But what's intriguing is the way in which these rebroadcasts are being done.

Similar to the Slingbox, end-users are using TV capture cards and simply streaming, through P2P technologies, the TV shows live from their home computers (with a slight delay) as they're broadcast. Unlike the slingbox, which is a device that controls your home TV and lets you change channels as you watch TV over the net, the service I'm referring to records only one channel. Interested in seeing another channel? Find a different user with a different TV and a different stream.

There's a certain similarity between this and other projects like Babelgum, Joost, and my personal favorite, the academic-only ACTLab.tv. And we've covered them before in this blog.

What makes this particularly interesting is that this is standard TV being encoded in real time into little bits and bytes, and illegally bypassing distribution restrictions.

For example, there are national distribution lines. I can't get BBC Three legally, no matter how much I like Torchwood, because I live in Texas. (Even the BBC's legal streaming service filters based on IP/location, so as not to tick off British taxpayers.)

There are also other distribution lines that we rarely think about. I can't get cable TV at work - not only is there no cable running to my office, but it would also be rather conspicuous to bring into the office, to set up, and to watch. ("Wait, how is Days of Our Lives relevant to network latency ping times?") But, with something like this illegal solution, (or the much more legal Slingbox) I could get live TV on my computer here. Or at least I could for about a day and a half before NetQoS IT had a strong talk with me about acceptable internet use policies.

Recreational network usage - especially video - has been a problem for IT departments. That's not news. What is news is that the idea of an always-on, streaming service for all live events, not just the ones lucky enough to be locally broadcasted. I mean, look at what happened when it became popular for other media - music and movies - to be copied illegally and shared via the Internet. There would be no iTunes without Napster, no Netflix OnDemand without the Pirate Bay. And just like an old cyberpunk novel from the eighties, illegal solutions where no legal solutions exist are a harbinger of a vast untapped demand. It may take a few years, but eventually someone comes along with a legal supply to answer that demand.

Live TV streaming isn't likely to go away. The good news, however, is that live TV streaming is distinctive as a traffic pattern - an anomaly detector with good baselines can, for example, pinpoint exactly when and where abnormal traffic usage is occurring. Unlike most viruses, streaming live video sticks to a schedule. No need for live TV when the Dodgers aren't playing.

By Brian Boyko
Editor, Network Performance Daily

Slashdot recently linked to an article from MacWorld showing that the amount of time that people spend watching online video has steadily increased. (In other news, water is wet…) Google's YouTube and Google Video served up over a quarter of all internet videos.

I think we can assume that a fair percentage of them were watched from corporate networks. Not just because of recreational use but because video is a very compelling medium that can convey work-related information, sometimes more quickly and more accurately than text alone.

For example, our Whiteboard Series was created with the expectation that people would watch our videos on WAN Optimization and VoIP from work, where they would find the information most useful.

One really can't just block YouTube, or Veoh, or Yahoo Video and expect blocking it to solve the problem of tying up vital bandwidth, because video is increasing not just as a 'bandwidth hazard' but as a method of communication. And it's only going to get more bandwidth heavy - and more useful - as MPEG4+ACC "Moviestar" Flash Video, or WMV using Microsoft's Silverlight increase the quality of online streaming video.

Don't think there won't be content producers - like us - taking advantage of this as well. High definition full-fledged video cameras cost less than $1000 these days. A flash-video "YouTube camera" can record 720p HD for less than $200.

The way to prepare for this is to have good QoS policies in place, so that the day-to-day business data transactions aren't interrupted or slowed when people access online streaming video - which is quickly becoming a necessity.

One big thing that complicates this is hard shut-off date for the end of all analog TV transmissions in the U.S. on February 17, 2009. It is possible to use a converter box to use an older TV with the ATSC standard - but most people will probably get a high definition television instead. High-definition television will prompt high-definition content. That includes home movies.

Right now, High Definition home video cameras are sold to computer geeks, early adopters, and indie filmmakers. They will be more widely adopted when most families have a high definition TV set and want to play back home movies. And as many YouTube videos are harvested from the ranks of home movies, it is possible to then imply that there will be demand for a high definition video hosting service.

That's going to mean more bandwidth usage. QoS policies become crucial.

By Brian Boyko
Editor, Network Performance Daily

My roommates and I have been chosen (if we choose to accept it,) to be a Nielsen family. And while, at first, I was thrilled to finally get the opportunity to stand up and be counted (I'm a fan of more cancelled series than I can count - Firefly, Brisco County Jr., Wonderfalls, The Critic, Futurama, Studio 60 on the Sunset Strip, Arrested Development, Farscape, The Tick, Justice League Unlimited…) it got me thinking about how, exactly, Nielsen is going to get accurate data on their version of "network performance."

First of all, my "Nielsen Family" consists of three roommates, including myself, who share a four bed, four-bath condo. I've never seen Patrick watch television. Ever. Mike supposedly watches TV but I've never seen him actually pay attention to it - preferring to leave it humming in the background to help him concentrate while he plays Warcraft III or Diablo II.

As for me, well, that's the stickiest of wickets. I own a TV but I only use it for my PS2 and Wii hookups. While Nielsen can track what people watch on TiVo brand PVR boxes, I'm not sure they'll be able to track my setup, which consists of a P4 Dell repurposed into a MythTV on Ubuntu box. The MythTV box connects directly to a business-class projector, but I end up using it mostly for DVD movies, YouTube, and downloaded videos. Even when I watch MythTV recorded movies, I usually end up doing so from my bedroom, which can access the MythTV box and stream the videos (and live TV!) over the LAN in the condo.

(Continued...)

Continue reading "Another kind of "Network monitoring,": Looking at the Nielsen Ratings." »

by Jeff Hicks

Voice over IP (VoIP) is a hot topic in enterprise networking - mostly because it's a challenge. In implementation, VoIP employs a number of different protocols, and has a unique set of performance requirements that make it a challenge for any data network. Examining VoIP protocols should give someone a basic idea of the performance requirements that VoIP places on the network.

First, there's call setup, which sets up everything needed to make the telephone connection between the caller and the recipient (or “callee”). This requires protocols that enable dial tone, number lookup, ringing, and busy signals before the call even occurs. In addition, the call setup protocols handle things that happen after the call - any resource cleanup and statistic reporting.

Call setup protocols use either TCP or UDP to transfer data during the setup and takedown phases of a telephone call. The messages are sent back and forth between the caller, recipient, and call server using well-known ports. For calls that travel between the VoIP network and the Public Switched Telephone Network (PSTN), the call server will converse with a VoIP gateway using the call setup protocol. There are many different call setup protocols, some standardized and some proprietary. Let’s discuss a few of these.

(Continued...)

Continue reading "VoIP Protocol Basics, and Why VoIP Consumes More Bandwidth Than You Might Expect." »

On NetQoS's internal boards, this news item from ZDNet prompted a discussion over Net Neutrality; and we had various questions and concerns about how recent developments would impact the Internet and our position as a network monitoring company. Below are some of the most insightful comments from the discussion that ensued.

Because it is a contentious issue, we have invited a few outsider experts to provide commentary. Tomorrow we will have commentary from Prof. Christopher Yoo at Vanderbilt University Law School, and we plan to follow it up in the future with commentary from other Net Neutrality issue experts as their schedules may allow.

(Continued...)

Continue reading "Network Neutrality Debate: An Introduction and Discussion" »

by Jeff Hicks

There's a number of reasons why a company would move to VoIP. Generally there's been some component of cost-savings - it may be in regular long distance savings, it may be in hardware cost savings (versus a PBX system), it may be that you only have one network infrastructure to deploy and manage.

But it's interesting how in the past couple of years, costs have become less of a factor in the decision process. Long-distance rates have dropped, so the cost factor is not quite as pronounced as it used to be, especially considering short-term rollout costs.

(Continued...)

Continue reading "VoIP Traffic Isn't Just Normal Traffic" »

• Network Performance Daily: Notes on the Gartner Summit in Las Vegas, Part 3
• eWeek: Study: Cisco Gains Market Share in Routers
• What You Need to Know About "ITIL Compliant"
• Computerworld: Giving YouTube its due
• InfoWorld: Will IT certifications pay off in the long run?
• The IT Skeptic: 10 other things you should know about ITIL

Continue reading "Daily Links: Gartner Enterprise Summit, Cisco router gain, YouTube and bandwidth, ITIL compliance, IT certifications" »