The following interview took place on December 4, 1996. The subjects include: research management; Ethernet and ATM network troubleshooting; field work and customer satisfaction; network applications; and proactive network management.
Net-Hopper Systems, Inc.'s philosophy is to provide its customers a "complete solution" to troubleshooting their computer networks. Based in Norcross, Georgia, it has a small-company corporate culture with about 20 employees.
Bert Lindgren, director of research & development, is the chief architect of PathMaster.
What strengths give Net-Hopper a competitive edge?
It's taking existing networks, the way they're built, and trying to make them troubleshoot-able. We offer a complete solution. Our competitors sell switches. Our complete solution takes into account the switches -- and analyzers and networks and network equipment and makes it one coherent system.
Not being the manufacturer of all the troubleshooting tools -- taking what's good from some tools and making them better -- has really paid off. We're a third party in a way, trying to combine tools, sometimes writing the software to glue them all together: our hardware with hardware similar to ours, with hardware completely dissimilar to ours.
What are your goals and objectives?
Our task is to get the troubleshooting equipment to the problem. I think there are two pieces to that. One is to make the interface to our software very easy and compatible with whatever the customer has, so that the information they have when looking at a problem is exactly what our software expects to take in. And to do that connection of troubleshooting equipment to the network problem.
The other is to support more and more network configurations, including new technologies as well as the varieties of available equipment. This [second piece] is being the best way to control a huge amount of network troubleshooting equipment, and the first is just making that scope easier to use.
How do you plan to achieve them?
By making our interface gather as much information from the network as possible, so the user doesn't have to supply information that's available elsewhere. By making it easier to use, like integrating it with more and more third parties, and then supporting a mass of hardware and being the best way to troubleshoot a network. It's a matter of incrementally supporting more and more hardware and adapting our technologies to similar problems occurring in different environments, like ATM. We've applied our solution to switch networks (Ethernet switches or frame switches) and now we control Ethernet hardware, and someday we'll certainly control more ATM hardware.
What's most important?
The complete solution: people buy from us something they can drop into their environment and maintain over the duration.
Where do you see opportunities for Net-Hopper?
The growth of network switching. There's two kinds of switching. There's matrix switching, which our hardware products do. It's really just connecting one wire to another and allowing those two to communicate with each other but nothing else; switching per conversation is not an option. And then there's frame switching, which people think of as Ethernet switching, where the user is connected to a box which routes each packet one at a time to wherever it's supposed to go.
People are deploying frame switching at incredible rates. It makes their networks better in a lot of respects, but it makes them a lot harder to troubleshoot.
Where do you see challenges?
The challenge is supporting as many Ethernet switches as we can. Also, nobody really knows where the network traffic is going, but they want to see it. If you have this cloud idea, with traffic going through this cloud, the troubleshooter wants to see this line between two users -- but doesn't have any idea how that line wiggles through the cloud. Those environments are a huge challenge for users to troubleshoot; they usually give up or try to glue together a bunch of indirect observations.
So I want, in the future, our customers to be able to say, "I want to see this conversation," and have our hardware and software bring that conversation to their analyzer, so they don't have to make inferences about the contents, but they can actually look at it, inspect it, filter it, save it, and do whatever they want with it.
What are your research goals?
Our research focuses on looking at the industry and its products, and then coming up with a view of them that's generic, so we can write software to our generic view and write modules to convert that generic view into whatever specific product the user might have. Instead of writing our software for one specific piece of equipment and then making everything else look like that specific piece, we try to come up with a generic view and force it on specific products.
I was fortunate to have a lot of time to think about troubleshooting networks. I took my view of what network troubleshooting really is and implemented it in PathMaster. It turns out that PathMaster can control its view, and we can write modules to control a wide variety of equipment, so it can implement that view into the actual piece of equipment.
How do you maintain innovative leadership?
The features that are spec'ed for PathMaster really come from troubleshooters, whose recommendations help make it unique.
What are your ideas for trying to do new things and develop new products?
One aspect is looking at network troubleshooting in general: what kind of information would the user like to have about the network in order to troubleshoot it better, irregardless of switches and other equipment; what makes troubleshooting better or a more manageable task?
Another aspect is, we want to control switches and move analyzers around from network to network: what would make that more flexible, more reliable, and easier to use and maintain? That's our main software product, PathMaster, and a lot of attention goes into making that better.
And then there's the networks that are really hard to troubleshoot -- or that no one knows how to troubleshoot. Is there something we can do there, to even get the ball rolling in troubleshooting these things?
So your research addresses those three questions?
Yes.
When you start a project, what sort of results do you expect?
This is where the difference comes in between the three. For example, if you want to make troubleshooting in general better, you talk to troubleshooters, network engineers, and you get their "wish lists". We have this established network technology, Ethernet, and dozens of troubleshooting tools, and they're all fairly sophisticated and mature, and you don't see any great leaps. So, when you talk to the users and they say, "I wish I could test my network in this way," you take those "wish lists" and figure out if they're implementable. We prototype them, implementing the ideas of experts, who kind of know what they want but don't know what pieces are available to tie together.
That's what PathMaster is. It's a result of that work from Interop. You get these network experts together who know what's available and can describe what they'd like to do -- and we turned that into PathMaster. It's a troubleshooting control system designed for Interop that happens to be useful in thousands of different networks around the world in different companies. But it started as a prototype for Interop.
Do you have some sort of timetable for improving PathMaster?
A month to 6 months.
When do you appraise the progress of the project?
Weekly.
Is there a systematic review of innovative projects all together?
Every 2 or 3 months. The salesmen are a good external party to include in these meetings, to get feedback about what would make PathMaster better, what our customers are complaining about, and what our customers think of proposed improvements.
Do your research teams include people from marketing, manufacturing, and finance?
We don't have that separation, but we gather a large number of opinions at the beginning, when ideas are forming. What we're trying to do is hammer out a consensus and decide on priorities: what are we going to prototype this on, what are our target platforms (operating system, network equipment).
So everyone participates in the research work from the very beginning to ensure successful innovations?
Yes.
What are you doing to develop your technical people?
We're training internally quite a bit. People talk about what they know, sharing expertise. Before we got busy last fall, we would hold 2 to 4 training sessions a week, which also helped to educate our sales force.
And Interop is a hands-on conference, and you get the most out of it by having people work on the network there. I've been doing it for years, and it's useful for getting our engineers to see a real network because we can't afford to buy one, one that mimics those of our Fortune 500 customers.
Can you give an outline for what else is needed to achieve success in some of your research projects, such as troubleshooting ATM networks?
So far, it's been a survey mission. We've talked to people and gotten ideas about what it means to troubleshoot an ATM network. (There aren't many people who have done that, deployed these things large enough that they cause themselves problems.) There's what you need to see when this problem occurs, and we've mostly gone through those. So we know of some problems that we want to solve, and what we need to do in order to see them and identify them. Then it's a survey of what can we integrate.
Really, it's an integration issue. We're going to write some analysis software for ATM networks, but the bulk of analysis is done by network analyzer companies, not Net-Hopper. We're going to do the analysis necessary to integrate the switches and the traffic, and get it to the analyzers and work with the analyzers to get the information they're missing to their users.
So it's a question of, what do we want to do? We can do this all out of band: we can duplicate the ATM network and spend money at each link in the ATM network to get the information out; basically building a duplicate network. But that's prohibitively expensive for a large network.
To do an in-band solution, one that gives us wide visibility but less in quality because we're depending on the same network that we're troubleshooting, we need to understand the components. That's really where we're going. We sell ATM troubleshooting networks, but they're not as easy to use or as inexpensive as they need to be.
What are the problems with other approaches?
Analyzer companies say (more to have an answer than thinking it's a good answer), put the analyzer somewhere: pick this link, between this router and that switch, and put your analyzer there. So you're going to spend $70,000 to analyze that link: you're not going to see anything else, but you'll know what you're seeing, and when this important link has a problem, you've put your $70,000 to use. Our approach is to spread that visibility around; say, 45% at 2 places and the remaining 10% across everywhere.
What do you find dissatisfying about your current situation?
The attitude of the network equipment manufacturers that we have to keep up with what they're doing: when they come out with a new product, or they change the way their current product works, they don't tell us. We have to find out after the fact. It's getting better, as their salesmen hear positive things from their customers about PathMaster and then tell their engineers about it. But it's still frustrating.
What's been your biggest success in business/research?
The fact that PathMaster's view of networks happened to control switched networks very well, and the fact that switched networks are just taking off. Everybody's putting them in, and we're one of the few solutions for troubleshooting them -- because we made a good decision about how we look at networks.
So this was an unexpected success coupled with an unexpected outside event.
Yes, the importance of the switched networks was a pleasant surprise. They took off rather than ATM. There was always this contention of "ATM to the desktop", and that just got obliterated by switched networks becoming popular. And we still really don't have a good approach for ATM, so we're very glad that switched networks took off!
Have you had an unexpected failure?
Not really. We wish ... no, I'm not going to make one up. [laughs]
Who are your customers?
Large companies because they all have large networks now.
How do you serve them?
Their computers and networks are critical, and they're willing to invest money to make them faster to troubleshoot. That's really what we do: we make it faster to start troubleshooting your problem. So if it takes you 15 minutes, an hour, or a day to hook up and start troubleshooting your problem, we reduce that to 0. That's 15 minutes, an hour, or a day of more uptime than you'd have without our solution -- and that extra uptime is worth money.
What do your customers find uncomfortable or even missing? Maybe this gets back to their "wish lists"?
Certainly their "wish lists". And sometimes they depend on us to help them with various tasks in our product. For example, installation: some deployments are new to us, so we help a lot with those to learn about equipment we haven't supported (or using it in ways we haven't supported).
We compensate for what they find uncomfortable by predicting what tasks they will find uncomfortable and doing it for them.
What are your goals for annual improvement in cost, quality, and customer satisfaction?
If customer satisfaction is less than 100%, then it's a bad thing. We don't set any specific cost or quality goals.
What time frame do you expect for a significant new market or application?
Four to six months.
How do you look for changes in technology and the economy that affect your company?
Doing Interop, especially the two big shows, where we try to get our hands on as much new equipment as possible. Talking to customers, sitting down with them and getting a sense of what they're doing and how they're making choices. We use the Web to retrieve product information and whitepapers on new technologies.
How do you use these changes as opportunities?
By supporting the new or changed equipment.
What do you read -- and what's your opinion of it?
A lot of magazines, but not regularly. They're bland and totally void of technical details. I read the editorials and letters-to-the-editor more than the front page because they come from people's experience.
What are some of the pressing issues that the company faces?
It's a matter of priorities. Taking our "to-do lists" and communicating with the sales force to determine how much time to allocate to supporting what new equipment.
What are the questions that don't have answers yet?
Will there be a standard way of controlling these boxes in a way that we do? Right now, we write custom control software for almost every model of every box. There's no standard for the most basic commonalities between all these products -- not even inside the manufacturing companies themselves. And then the stuff we work with is not common across all the products and not used everyday except to troubleshoot.
This is good for us because PathMaster supports a variety of controls, which took a huge investment of effort on our part. Any competitor will have to exert as much or more effort -- unless there's a standard, and it becomes easy to support every switch.
What has already happened that will create the future?
The deployment of large networks -- and the problems with them. The networks are getting more complicated; the problems are slightly fewer, but each one is much harder to fix.
What changes in industry, science, and technology have already occurred, but have yet to have full impact?
Networks. I think networks could sit at their current level of speed (and maybe deployment). The idea of networks is to help people communicate with each other, and so much more could be done with what's already out there. I don't understand why people want to deploy more bandwidth than there is already. I can understand deploying the bandwidth technologies that already exist, but I can't understand wanting to deploy more than 100 MHz to the desktop -- because I don't think that 100 megabits is being taken advantage of. For a server, I can see that; but from a user's point of view, I just don't get excited about anything more than 100. You can do more TV across 100 Mbits than a user can watch.
Does that underutilized bandwidth have any implications for Net-Hopper?
There's going to be a flood of applications because there's this untapped resource. Companies are going to write innovative apps to use it. Those apps are going to become more and more important, and the importance of network apps is a great thing for Net-Hopper because it drives the need for uptime -- and intolerance for downtime.
What changes to PathMaster does this demand?
Network growth has a physical impact on our product. People are using it to control larger and larger networks. PathMaster used to have a list, with networks on one side and analyzers on the other: click on one, then the other, and connect them. But what happens when the list is thousands and thousands of lines long? That doesn't work anymore. We had made that interface easy to use, but it just didn't scale at all.
What we've gone to now is, integrating PathMaster with the applications these companies already use to draw their networks. That's the interface they should be using to troubleshoot. Our focus right now is making the interface to PathMaster less visible. The only appearance PathMaster has to the user is a menu that says Analyze.
What are some promising research fields?
Resilient networks; proactive testing or troubleshooting networks; finding out what it means to test a network. You ask about testing networks, you get different answers -- and you should because every company has a different need for a network (different applications with different requirements).
People are very excited about proactive management of networks. It helps find things before they break. As they're breaking, you alarm on something and get someone's attention and discover what the cause is before it becomes deadly. Another side is, causing your network pain and seeing how it does: every morning at 3 you beat on your network and see how it responds. Also, there are things you can do during the day, not pain-causing but more status checking, to make sure your network's behaving as expected.
Do your company's research interests involve computer simulations?
In its day-to-day use, PathMaster is simulating networks and then implementing its simulation into hardware. We can simulate some box being in one of our networks, but what we don't have is a tool to build simulated networks.
It would take a week to design a single configuration of a test network. I'd prefer to design these rules: this is what a backbone looks like, this is what a department (or a floor of a building) looks like -- rules for a high-rise, with switches on every floor, ringed together with a FDDI ring.
What other Southeastern companies are doing interesting research?
Wandel and Goltermann in Research Triangle Park. They're asking the same sorts of questions from the analyzer point of view: what can analyzers do to display or gather information better.
If you could speak with anyone, who would that be?
Well, there's this guy at 3Com who won't return my calls.... [Two days after the interview, he did.]
Relevant links:
More information on other topics may be found using Google.
|