SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Strategies & Market Trends : Technical analysis for shorts & longs
SPY 672.04-1.7%Nov 13 4:00 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Johnny Canuck who wrote (35086)11/9/2001 6:36:00 PM
From: Johnny Canuck  Read Replies (1) of 67936
 
Juniper founder sounds off on QoS, memory bottlenecks
By Rick Merritt
EE Times
(11/09/01, 5:44 p.m. EST)

Pradeep Sindhu has learned something about riding roller coasters. As the founder and chief technology officer of Juniper Networks Inc., he has seen his startup go from being the poster child of the Internet go-go days in the late 1990s, to a company forced to stagger through layoffs during this year's dramatic downturn in telecom spending.

Sindhu is staying the course, championing his vision of building industrial-strength Internet Protocol networks and challenging giant Cisco Systems Inc. But the pressure is on. Juniper's stock has plunged from a high of about $240 per share in October 2000 to less than $25 this past week, despite the fact that the company will grow to just under $1 billion in revenue this year.

On the technology front, Sindhu is concerned that key network quality-of-service standards are not evolving in a realistic way, and that the memory industry is still too focused on the needs of computer makers. He spoke recently with EE Times at his company's headquarters in Sunnyvale, Calif.

EE Times: What do you think are some of the most pressing issues in communications technology today?

Pradeep Sindhu: The industry needs to understand we need to provide reasonable QoS [quality-of-service]. The trouble with QoS is you need to have it at every point in the network where there might be congestion. It's enough to screw you up if at any point in the network you do not have this.

But we need to walk before we run. We need to agree on a small set of QoS levels in access and core networks. That would be a huge step forward.

The people doing the [QoS] standards have agendas other than making things work. Some people just seem to want to earn their PhD degrees. Many proposals are so complex to implement they cannot work. Groups that are in various forums defining 64 levels of priority have lost touch with reality.

I don't want to single out any one particular group, but the work as a whole is getting too complicated. It is similar to the work with ATM [asynchronous transfer mode].

Once it is proposed, 95 percent of it will go unused and will just sit there like a stack of paper six feet high.

How the network works is too hard for anyone to understand a priori. So you have to deploy something, see how it works, get feedback and continue. There is no utopia in getting it perfect.

EET: What are your key hardware concerns?

Sindhu: It turns out the DRAM industry has not served us well at all. We have particular requirements that computer makers don't. Maybe we don't have enough volume to really attract their attention.

For us, the amount of memory we need is based on the round-trip time multiplied by the bandwidth. So to provide lots and lots of bandwidth you have to gang up lots of memory ICs in parallel. Rather than bringing more bandwidth to the chip, the capacity of the chip is fixed by the round-trip time. The DRAM industry has not understood that concept. So now we are talking about all kinds of alternatives like DDR-2, and some people are talking about DDR-3 and Rambus as well.

[Harry: RMBS has been talking about this for about the last 3 Q's. INTC licensed the RMBS technology for non-PC applications in the new licensing agreement they signed about 2 months ago.]

Even in SRAMs there's a special kind of access you want in routers and switches. Having a new capability to burst in two, four or eight cycles of data ups the bandwidth [of an SRAM].

But we use a metric of address rate, the rate at which you can get a new address. So the data we want to access is small — just 16 or 32 bits — to change an address, then move on to the next one. We want the address, not the data rate, to be fast.

EET: What's your take on network processors?

Sindhu: Ever since Juniper started selling systems, we've been approached by a lot of companies about network processors. In the early days they were focused on the core routers. Now they are focused on the edge and access routers. Their advantage is they are programmable and thus flexible.

We are trying to work at levels of performance where we require customized solutions. We are stretching the limits of what the technology can do. So it occurs to me that either we are wrong or the network processor companies are wrong. It turns out we have been right so far, not because of any profound insight, but just because it takes X transistors to do a function, and to layer a programming level of interpretation on that causes a 10 to 15 percent hit in performance.

If you step back from the highest levels of performance, network processors have a place. So in spaces that are not at the top of performance and that have a high rate of change, we will use them.

[Harry: What does this do to the total market assumptions of companies like MRVL, LNOP and the MMCN division of AMCC?]

EET: There is talk Juniper will go to full-custom design for its next-generation core router ASICs. Is that true?

Sindhu: If performance requirements keep going up faster than silicon technology moves, you have to map your solution more efficiently to the ASICs, so we may need to custom-design them. But you don't take that need lightly because it adds to the development time.

EET: Juniper recently said it expects revenue to be flat for the next 15 months. How bad is it out there among your carrier customers?

Sindhu: People have not distinguished between growth in demand at different layers of the network, and there are many layers — digging trenches and laying fiber, putting in amplifiers, dense wavelength-division multiplexing, layering on switches and routers, and then services. When people say the network is overbuilt, it's at those layers that are further down. That's my view.

The demand in terms of bandwidth has slowed down some, but we think demand will average out to 80 to 100 percent annual growth in bandwidth.

EET: Is it hard to hang on to your best engineers with your stock price so low and new startups still getting funding?

Sindhu: We can't control the fact that we've gone through a market that is irrationally exuberant followed by one that is irrationally depressed. What we can control is our ability to continue to engineer great products. I think people understand our company has real value. We are solving what I believe are fundamental problems in the network infrastructure.

Engineers want to make a difference. No engineer wants to work for five years and see his effort go unused. Our goal is to have as short a pipeline as possible from the brains of our engineers to the arms of our customers. If you are making a difference in the industry, people want to be there.

EET: How would you describe your job?

Sindhu: Different CTOs occupy different levels of abstraction. What I enjoy doing is building products. Another thing I like to do is define what we should be building next. I also enjoy solving hard problems.

I make a point to see as many customers as possible. My customers want to build networks that provide value for their money. Juniper can build networks that host multiple services because Internet Protocol is the basis for a multiservice network. Before Juniper delivered its Internet Processor 2, it wasn't possible for IP to support multiservice networks except on paper.

EET: What are the limits of IP?

Sindhu: It comes down to scalability. You can have an all-Ethernet network and layer IP on top of it. But if you try to use Ethernet beyond the scale it was meant for, you will see issues. We are seeing this ambiguity in the metro area today [with resilient packet rings]. We can now provide the type of public network and virtual private network that offers users the same guarantees in security and data and service-level agreements as frame relay and ATM.

[Harry: Maybe JNPR can, but getting old time telecom engineers in the carriers to accept that and integrate it into hybrid SONET and IP systems is another story.]

When you get to that point it's game over. There is no need for frame relay or private lines. It is all about economy of scale.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext