Verizon and NBC are working on serving up TV shows to home computers. The problem is, high definition video, (and I've done some HD video work for the Web - shameless plug), takes a whole mess of bandwidth.

Now, the obvious solution for NBC would be to move to some sort of peer-to-peer distribution system, right? I mean, it works for Linux distros.

The problem is that a normal peer-to-peer connection doesn't distinguish between the cheap local links - that is, links on the same ISP, in roughly the same geographic area - from the expensive remote links. So while P2P provides a more cost effective solution, it doesn't provide the most cost-effective solution for the ISP.

A third party, Pando, has developed a P2P system for pre-authorized, pre-approved content, and has come up with a way to force peer to peer connections to look for local nodes first. This increase the efficiency of the system, lowers the cost, and generally increases the performance of the streaming/downloading video.

This is exactly the type of thing we talk about when we say that how the application is coded can have a huge impact on the application performance over the WAN. Sometimes instead of needing more bandwidth, you need to find a way to make the apps work more efficiently.

In this case, decentralized P2P systems developed after the destruction of Napster. Though they were much less likely to get shut down by the RIAA, they were also much less efficient. This dominated development of P2P applications for years. But for offering only pre-authorized content, a centralized system - especially one that takes advantage of the structure of the physical network, makes a certain bit of sense.

NBC will be offering Verizon customers their shows via Pando's P2P service - which they're calling P4P, later this year. The name is a logical outgrowth, P2P, or "peer to peer," versus P4P, or "peer for peer." P3P was disregarded because it sounded too much like PCP. And if a kid with a lisp goes around school saying: "I downloaded the latesth Methallica album on P3P" and a teacher hears: "I downloaded the latest Metallica album on PCP," well, that's just not going to be a story that ends well, now, is it?

There's only one problem with Pando's plan: Each ISP will have to give up information about its subscribers in order to participate - that is, the Pando platform requires knowing which nodes are "local" and which nodes are "remote" in order to optimize for the local connections:

For other ISPs to reap the benefits Verizon did in the test, they too would have to share information about their networks with file-sharing companies, and that they normally keep that information close to their chests.

''That's one of the objectives we have to solve -- how are we going to consolidate this data and distribute it?'' Pasko said, adding that the result of the test gives ISPs plenty of incentive to collaborate.

(Okay, maybe there's two problems: No offense to NBC, but when your biggest hit is a veritable case study in game theory… you need some new shows.)

Today marks the official start of the South by Southwest (SxSW) Festival in Austin - for readers outside of Austin, SxSW is a combination film, music, and technology festival. Despite its increasing commercialism, the week-long traffic slogs, and the temporary 50 percent increase in man-purse slinging hipsters, SXSW is the premier forum for new music showcases, and the film and digital conferences have attracted some notable and useful panelists. SxSW is one of the reasons Austin is at the top of so many "best cities" lists.

Additionally, tomorrow marks the start of the Austin BarCamp "un-Conference," which is what you get when you try to "get the anarchists to organize" a tech conference. BarCamps are open, participatory workshop events which focus on open-source technologies, and early-stage Web applications.

Of particular interest to network engineers and those interested in Web application performance are these particular events:

BarcampAustin: Usability: Will Users Wait?
Saturday, March 8, Time To Be Determined, GSD&M, 828 W 6th Street., Austin, TX.

Elizabeth Gibson and Lin Howe, AT&T User Experience Design, want to talk about how long of a delay will users tolerate before becoming frustrated or dissatisfied and abandoning the website? Is there anything that can be done to help mitigate a bad user experience?

SxSW: Catching up with Accessibility: The Basics Quickly
Saturday, March 8, 10:00am, Room C, Austin Convention Center

Shawn Henry of the W3C Web Accessibility Initiative will demo how accessibility design can be incorporated into Web sites to allow people with disabilities or people using ways of accessing the site other than the traditional Web browser.

We'll demo how accessibility makes your website available and more usable to people with disabilities; to people using mobile phones, PDAs, and other such devices; to people with low bandwidth connections (which is more of a problem than many are aware of in the U.S. and throughout the world); to seniors, an increasingly important demographic; and others.… This session runs through the easy things and the most important things you can do now to get your project up to speed on accessibility.

SxSW: Crunching and Streaming: Online Video Distribution Challenge and Opportunity
Tuesday, March 11th, 10:00am, Room 19AB, Austin Convention Center

Brendon Mills, CEO of RipCode, Todd Bryant, CEO of Netcast HD Inc., Jeff Kramer of Policyot Labs and others talk about digital video distribution.

Video compression is critical technology for media convergence, and the growing demand for online delivery of high-quality, preferably high definition, video is driving significant innovation in the areas of compression and distribution. This discussion focuses on the significant challenges and opportunities associated with the evolution of online video delivery.

SxSW: Take Municipal WiFi Back
Tuesday, March 11th, 3:30pm, Room 8, Austin Convention Center

Rich MacKinnon of the Austin Wireless City Project, Silona Bonewald of the League of Technical Voters, and others talk about the problems with top-down municipal wireless projects in San Francisco, Chicago, and Philadelphia, and takes a look at the viability of Muni WiFi.

Grassroots approaches to WiFi have focused on leaving the bureaucracy behind, but face challenges in terms of expanding their reach and gaining momentum. Top-down municipal networks promise ubiquitous coverage but have run up against formidable barriers concerning cost of construction, cost of maintenance, and implementation. Both have a goal of eliminating unlawful WiFi "piggybacking" that opens up millions of Internet surfers to dangerous invasions of their personal privacy. Stop by this panel to find out the latest about attempts to bring safe, secure and ubiquitous WiFi coverage to our cities.

by Brian "Scrabble" Boyko
Editor, Network Performance Daily

When a company like Cisco goes into "new media marketing," it doesn't mess around. To promote the Cisco ASR 1000 WAN-edge router, it started a Facebook Group, a Second Life Site, and a slew of holiday mascot viral videos. But that's not the big one.

It won't win any praise from Ben "Yahtzee" Crowshaw, but Cisco created an entire video game around the router. The game, implemented in Shockwave, pits you as the lead agent, piloting an ASR1000 router - yes, piloting - across cyberspace, picking up packets according to quality of service priority, and delivering them across the network. There are also bonuses related to the router's capabilities, such as a 'throughput upgrade' that increases the speed of your… uh… "hover-router," and a "parallel processing" upgrade that allows you to pick up two different color balls - I'm sorry, I mean two different types of network traffic packets - instead of having to clear the packets from the board one color at a time. You might expect that there might be lasers or something coming out of the 'routercraft' but it's a router, so it doesn't have any lasers.

It shows that Cisco can have a little bit of fun with itself, and doesn't mind others poking fun at it either, otherwise they never would have put this out there for people like myself to poke fun at. But, as a game, it's amusing for five minutes, and certainly a great way to justify playing a video game at work, but if I'm going to be playing a video game at work, I'd rather play a game where I didn't actually learn anything about routers. There's a reason that despite the obvious pun, the Valve game developers didn't have GLaDOS go on about the relative merits of different firewall solutions as she tried to incinerate you.

The game itself may miss a few marketing targets, for example, the "space router" was frustrating to steer, even after the power-ups it was kind of sluggish, and it would frequently get rammed into the walls. Sure, I'm remembering the parallel processing thing as it's a great way to illustrate that particular feature, but I also remember a frustrating box that ran slowly and crashed repeatedly. I don't say this to knock at the router it is supposed to represent, but merely to knock the representation. Then again, the real ASR1000 can't fly around the room like a robot Peter Pan, so it's kind of a wash.

At any rate, the game is simple, amusing, and illustrates the main points, which is about as well as you can expect from a marketing mini-game, and hey, I'm talking about it and you're listening, so it can't have failed that badly.

In NetQoS's resource room, we've got a free Web-based app called the NetQoS Network Estimation Tools (or "latency calculator" for short) that allows you to calculate the theoretical latency of network connections under a number of different scenarios.

The NetQoS Network Estimation Tools, a.k.a. latency calculator

Allow me to clarify: A number of different plausible scenarios. Like, for example, if you knew that there was a 5ms router latency, a 20ms server latency, and a link distance of 100 miles, you would be able to get the overall theoretical latency of that connection, whether it's point-to-point or frame relay. However, it will not give you the latency involved in IP over Avian Carrier connection. Plausible scenarios only.

In addition to the main latency calculator, there are several sub-tools, such as an Ethernet packets per second calculator, a link speed calculator (with packets per second and packet size as inputs), a multicast calculator that will give you the Multicast Low Order and a MAC address, a HEX to decimal converter, and other tools useful for the network engineers at their desks and in the field.

The calculator was invented as a teaching tool by Bill Alderson, who has been diagnosing problems in large-scale networks for 25 years. We asked him what some of the uses for the calculator were out in the field.

Bill Alderson: You can use it to calculate how long it would take to do an FTP transfer from a 400 MB file to… whatever. So it's pretty easy and simple, it does take a little bit of instruction, but the latency calculator counts the number of round trips that are required and you can make the size whatever you'd like. Instead of having a packet size with a 1500 or an 8000 byte MTU maximum, you can simply crank in a 450GB file, and it'll tell you how long it'll take to serialize that file across the links you have selected.

You can put in all of the various entry points which are drop-downs of Ethernet, drop-downs of T1s, sub-T1 speeds, and you can just pick those in there, and then you can change all the sizes and determine, theoretically, how long a transaction should take.

Let's say that you were in Dallas, and you wanted to do a transaction with a server in San Francisco (or Japan or what have you). All you have to from your desktop is to go and ping your destination and find out what your latency is. Then you can make sure that the latency you put in is the same the calculator has. We don't express that latency necessarily in exacting numbers, but we have some general rules the industry has used. I like to teach people from a standpoint of being able to do the math in their head eventually after they've used the calculator 10 or 12 times, they can do this math in their times.

So rather than doing this an exact 186,000 m/s speed of light transaction, I broke it down into very simple things like 100 miles is about 1ms of latency. That way, not only can you use the calculator, which will also calculate serialization, but most of the latency calculations are things that are changing all the time - not exact numbers. The 1ms per 100 miles or 1.5 seconds for 100 miles of frame relay - it works out. It's very very close, especially for the type of things that people want to do.

You try and break down very complex things into very simple things so that the average man or even the non-average man who doesn't calculate those things very often can have an anchor to information that helps them begin to do it in their heads so it's second nature when you do a ping from your desk. If you do go in and do everything exactly, down to the nanosecond, the largest part of the audience's eyes glaze over, and they're completely lost.

When you see when something's 2000 miles away and comes back in 40ms, you see that you're very close to the theoretical. But if it comes back at 92ms, you're going to scratch your head and say, "That's too far away from theory. I'd better do an investigation and analysis to find out why it's so far away from the theoretical." We're trying to give the average man the ability to calculate quickly and see the many outcomes of many different examples, so he can commit these things to memory eventually.

If you have a lot of complex things, you can crank it into the calculator, and people love it. We built it for a learning tool, but absolutely, I've used it in reports and helped people understand. That's what we're looking for: Take theoretical numbers that are very close, and help people simplify those so they can get to the answers and then learn those things so that they eventually don't have to go to the calculator.

Let us know what you think of the latency calculator in our comments section below.

We've recently been linked to by Slashdot again, and we're getting a lot of traffic from StumbleUpon, so we thought this would be an opportune time to "share the love."

Recently, I found out about Ryan Davis, a network engineer at the University of Missouri. He's publishing a personal blog dealing in large part with network engineering called RyanDavis.net, and one of his first posts is a review of O'Reilly Publishing's "Network Warrior: Everything you need to know that wasn't on the CCNA exam"

Here's a quick excerpt, but if you're interested, you really should read the whole thing at RyanDavis.net:

Network Warrior bills itself as "Everything you need to know that wasn't on the CCNA exam" and that claim is quite accurate. The book is very Cisco centric, both covering configuration examples in CatOS (considered by most to be deprecated) and IOS. While I don't come from a Cisco background (but just about every other background) I still found this book very enjoyable because it combined the Why with the How. I should explain…

Most books on network engineering topics, or even computer or technical topics in general, usually cover one of two sides of the field; either the history and theory behind a technology, or the implementation and maintenance of its solutions. I feel like this book joins the two. In doing so it really fills in the gaps that I found in my expertise where I either knew about something, but not how to do it, or vice versa. By creating a bridge between the two, author Gary A. Donahue provides the catalyst for several of those "Ah-Ha!" moments, even for seasoned professionals.

With mysteries abounding about the undersea cables cut in the Middle East, Network Performance Daily talked to Eric Schoonover, a senior analyst at TeleGeography, a market research firm specializing in telecommunications supply, demand, and pricing. We wanted to get to the bottom of what's happening with the undersea cables and widespread network outages, and see if there's any truth to the various rumors floating around.

Network Performance Daily: Could you tell me a little bit about the effects of the undersea Internet cable cuts?

Schoonover: The undersea cables that were cut are part of the global network and in fact a heavily used part of it. And as such when they were cut, it limited the amount of capacity connecting the Middle East to Europe. I'm specifically referring to the cuts on January 30th - the first two. And because of that, the Internet and things that relied on the communications to Europe, you know, phone traffic and business-to-business type communications were severely hampered until the carriers that were affected were able to find alternative routing.

Network Performance Daily: When they were able to find alternative routing - was that immediate? Did the traffic find they couldn't get connectivity and just routed around it, or did someone have to pull a switch somewhere?

Someone had to pull a switch. With this amount of capacity, in terms of percentage, there's not that level of restoration available on the direct route. So, for instance, I know an affected carrier that has been quite vocal about the things they have done to restore capacity to their customers - even to the point of having to enter into some short-term contracts to transit traffic around the other side of the world, you know, via India, Sinagpore, Japan to the U.S.

So it does take a little bit of time. And each carrier that was affected responded a little differently in a little different time as well. So anywhere between a few hours to a few days to get service back, depending on the type of carrier and their relationships with the wholesale providers in the area.

Network Performance Daily: Has this increased network latency for those kind of connections?

Schoonover: Absolutely. Two kinds of factors increasing the latency - anytime you go the other way around the world from the Middle East, it's going to add a little bit of distance and distance equals latency, because of that "physics" thing. The other thing is that 75 percent of the capacity connecting the Middle East to Europe was cut, which, when you try to move that type of demand around, then you're going to create congestion on the remaining line.

Between those two factors there is a higher amount of latency and it does take some creativity on the part of the carriers to keep their business customers operating and keep their voice calls at a higher performance level.

The thing to suffer the most would be the Internet. Because that's not as latency sensitive as voice or real-time business communications, the carriers allow it to be more affected by the problems than the other services.

Network Performance Daily: Is there any basis for any sort of conspiracy theory here at all?

Schoonover: No, I don't think so, really. Cables are damaged with relative frequency, and I think that this is more along the lines of coincidence that there were a few different incidences within a couple days than anything else.

Network Performance Daily: What about the two main lines?

Schoonover: Well the two main lines were close enough that it probably was the same event. Whatever cut one most likely cut the other one as well. I know that the initial speculation was that a ship had dragged anchor across the two cables which would very easily snap them. That was later refuted by the Egyptian regulator. You can then look at things like seismic or geological events, something like that.

But most likely because those cables went down together, and they were so close - most likely that's one event.

The other cable breaks in the gulf - there's two others - were separate events that happened within a few days of the initial one.

Network Performance Daily: So if this stuff happens all the time, what can companies do to preserve mission-critical network connectivity and performance?

Schoonover: Finding restoration paths and having existing agreements for having restoration in place is very important, and many carriers have diversity in route and upstream providers, as well as the option to exercise a backup plan. And as we've seen, even if it takes a few hours to a day to get things back up and running with some amount of regularity, that's a result of having these pre-existing redundant relationships available.

I think businesses are getting smarter about that and I think carriers as well, particularly after the Taiwan Earthquake from December [2006], that cut a significant amount of capacity in the inter-Asia region. A lot of businesses quickly realized that their disaster-recovery plans were not sufficient, and went about getting better ones.

The fact that businesses have been able to recover relatively speedily is indicative of good planning to a large extent.

Network Performance Daily: How important are these sea cables to global communication?

Schoonover: Very. A lot of people don't realize, but undersea cables are the backbone of the global communications network. Obviously Europe has a lot of terrestrial cable as does the U.S., but as soon as you need to cross an ocean, the bulk of the traffic is travelling via submarine cable, not satellite.

Network Performance Daily: Well, why couldn't we just use satellite?

Schoonover: Higher latency, less capacity, and more expensive.

Network Performance Daily: What's the most important thing that people are learning from this incident?

Schoonover: I think there's a fragility to any sort of infrastructure, and I think you can take away that businesses and carriers do need to prepare for the unexpected. With the Taiwan earthquake taking seven of eight cables, and this taking two of three on a particular route, there has to be physical redundancy, both geographical and capacity.

But that being said, the carriers knew that and they're working towards it. There's at least four cables being planned and built on the exact same route that the cables that were cut are on. It'll be another year or two until the new cables are operational, but the demand for this type of thing was known and is being addressed, it's just that the timeline didn't work in the favor of the Internet users in the Middle East.

Network Performance Daily: The whole thing - just to get this whole conspiracy thing out of the way - what would it actually take to knock Iran's communication infrastructure off the Internet?

Schoonover: Well, it would take a lot more than what's been done. Really, when you look at Iran's connectivity, while they have been affected by the cable cuts, they are not the most affected country. They have terrestrial connections to surrounding countries, satellite connectivity, and redundant submarine connectivity.

Really, what's been done, if it were a directed attack, it has not been particularly effective.

• Network World: What those oceanic cable cuts mean to you.


• Wired/Threat Level: Cable Cut Fever Grips the Web

How is your company weathering the cable cuts? If you've been affected, let us know how you got back up and running by leaving us a comment below.

Recently, Network Performance Daily did a story on the Cisco Nexus 7000 switch, which had recently been announced by Cisco and will likely be a very important piece of enterprise hardware.

After our article, Douglas Gourlay, the Senior Director of Marketing and Product Management of Cisco's Data Center Business Unit, contacted us and pointed out that we were mistaken about some of the capabilities of the Cisco Nexus 7000 and so we invited him to do this podcast with us.

The Aberdeen Group, a provider of business research services surveyed 205 organizations last month to identify best practices for enterprise network visibility initiatives and controls. They called the report "The Real Value of Network Visibility."

In the interests of full disclosure, it should be said that NetQoS co-sponsored the study but we did so only after the survey was conducted and the analysis complete. That said, though, the study pretty much validates our entire "performance first" approach towards network and application performance management.

What the Aberdeen Group suggests is a PACE model (Pressures, Actions, Capabilities, and Enablers) to achieve corporate goals. The idea is that businesses are pressured to be responsible to customer needs, and the actions that are effective are to establish a proactive control of the network. In order to do this, you need to be capable of defining your escalation pathways for network performance issues, having normal networking performance baselines, understand interdependencies between applications on the network, be able to segment round-trip application response times into delays caused by the server, the network, and the application, and finally, have a centralized point for looking at the network performance data.

Frequent readers of this blog will no doubt notice that this is the point where I usually mention that NetQoS makes some of the products which enable those capabilities. The Aberdeen Group reports that these "enablers" are network performance monitoring through a Web interface, tools for remote analysis and troubleshooting of network performance, tools for creating custom profiles for monitoring groups of network hardware, a unified network performance and security platform, tools for Netflow data analysis, and a lab environment to simulate network performance.

There are some other gems in there to be found. The survey results showed that that top 20% of performance scorers:

• Were the most likely to have the capabilities and enablers mentioned under the PACE model.
• Were spending less time on troubleshooting network performance and application performance, managing changes to network design, or enforcing network usage policies.
• Were much more likely to have merged application and network management into a single job role, and more likely to merge the application, network, and systems management teams into a single organizational unit.
• Were able to fix problems faster and less likely to rely on calls to the help desk for determining network problems.

What do you think about the Aberdeen Group's report? Feel free to leave a comment below.

By Nathan Bragaw
Business Development Manager, NetQoS

NetQoS European Tech Rep. Peter Frame and I made a trip to Moscow last month to attend a network management event hosted by our new Russian partner, UNICORNS. I thought I'd share a few observations from that trip.

First, the obvious: Russia is cold. I was born in Maine and been in Minnesota in Winter, but Russia, complete with snowfall and brisk wind qualifies as the coldest place I've ever been, and that includes Minnesota in Winter. On the plus side, the food is fantastic - I didn't realize I liked borscht until I ate at Taras Bulba on Petrovka Street - wonderful Ukranian and Georgian food.

It was clear from the wonderful work our local partner, Boris Goldshteyn, did with getting some of the biggest companies in Russia to attend our first network management event in the country that the Russian economy is in full throttle.

I am always fascinated by how different cultures and environments change the needs of our customers. In Russia, it's not that their network performance problems are any different. Instead, they are facing the same problems, like VoIP performance and WAN Optimization difficulties, but they are moving at a faster rate. This is largely because they are not confined by the fiscal restraints that companies in the U.S. face due to the fallout of the dot-bomb era. Companies in Russia want to invest in technology but are challenged to ensure that the technology they seek will meet the needs of their business. The network engineers we talked to there are looking at massive growth, the push for more current technology, and demands for understanding application performance over their networks.

What differences in culture and environments have you found when working on multinational IT projects? Feel free to tell us about them in the comments section of this post.

by Brian Boyko
Editor, Network Performance Daily

The frustrating thing about IPv6 is that as much as we hate to think about it, as much as the transfer might irk and infuriate us – we’ve just about filled up IPv4, and that means that someday soon, we have to move to IPv6.

You can only delay the inevitable, which, right now, looks like it will happen in less than five years.

One of the big selling points of IPv6 was autoconfiguration. Sure, it’s a pain in the but to enter in longer numbers, so the IPv6 standard was designed so that you’d have to enter in those numbers less often. Through “stateless autoconfiguration,” you eliminated the need to set up DHCP.

But there are some advantages to the existing DHCP protocols, especially with visibility into the network, tracking and debugging features, as well as additional manual control - and so many companies, among them Cisco, are pushing for DHCPv6.

In the stateless autoconfiguration, you get true plug and play. The client is assigned an IP when it connects – without the need for a special server. Boom. Done. That’s perfect for portable devices, accessories like printers, and smaller operations in home and small office networks.

But DHCPv6 lets network manajers know what devices are connected to the network, as well as their IP addresses (and if necessary, to reassign them.) This is a major component in troubleshooting and monitoring the network to improve performance.

The downside: In addition to the complexities of changing over from IPv4, network administrators and engineers would have to manage a DHCPv6 network service as well.

Now, as mentioned, small home networks will find stateless autoconfiguration to be a boon, and ISPs will also be happy to avoid using DHCP to assign the addresses of the end-user. But for everyone else, DHCP is no longer a requirement – it’s a choice.

The odd thing about choices in corporate IT environments… it’s usually a short time to solve a problem, but it can take forever to make a decision.