Foundry Strikes at the Core

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 5 / 13 > >>

OldPOTS 12/5/2012 | 3:22:59 AM

re: Foundry Strikes at the Core "These are (IP) challenges that the PSTN does not have. Some would say that this is because it was designed properly :)"

While the control plane (logic) is moving closer to the user, enabled by IP, the IP networks have a lot of work reinventing the wheel. Check the logic in a high reliability SS7 router, the STP. Oh it uses HDLC, how different is that from the IP base???

And then there are those new black/crank phones in Louisiana. My co-harts posted a sign in my cube GÇô There is a Plain Old Telephone in the network somewhere. For now that Class 5 must support until eye peers reinvent the wheel to support them.

OldPOTS

Reply | Post Message | MESSAGES LIST | START A BOARD

paolo.franzoi 12/5/2012 | 3:22:58 AM

re: Foundry Strikes at the Core
Heck OldPOTS, I think there are coin-first PAY phones in North Carolina still.

I know there are analog carriers and analog loop extenders still on some loops in Montana.

Heck I even know of places with 80kft and 120kft loops.

I think some firehouses still have mechanical klaxon bells.

seven

Reply | Post Message | MESSAGES LIST | START A BOARD

sigint 12/5/2012 | 3:22:57 AM

re: Foundry Strikes at the Core These days one 12" wafer will have between 1000 and 10000 chips on it, generally the fab wants to run at least 12 wafers per lot and to keep the process / product centered they usually want no less than 1 lot per month. So the minimum volume needed to utilize this IC production flow is between 100K and 1M units per year. Even at these volumes the Mask costs of over $1M per mask set (2 sets minimum per new product) account for between $2 and $20 per chip. If your volume is less than 100K than do the sums yourself, however dont forget to halve or quarter your yield because process drift and the odd bad lot will kill you.
__________________________________________________

Good post optoslob. I used to work for this very large silicon vendor, where costs were internally optimised by each division pushing out chips (initially) on shuttles. Effectively, multiple designs share a wafer. That's a lot more work for the fab folks, though.

I want your opinion on the following: I'm a system house who wish to do their own silicon. I require 5 devices (of varying die sizes) to complete the equation. Would the numbers line up in my favour if I could build wafers with all of these chips on it, in the right numbers? (i.e., if I needed 10 times as many framing devices as switch fabric chips to a system, there would be 10 framer dice for every switch fabric die on the wafer.) I would also probably like to split functionality into smaller chips to improve yield.

And, assuming all FC, can't these be attached directly to boards rather than use expensive packaing. (testing might prove a nightmare, though). Your comments. Discussions like these make light-reading worthwhile.

Reply | Post Message | MESSAGES LIST | START A BOARD

douggreen 12/5/2012 | 3:22:57 AM

re: Foundry Strikes at the Core First, let me state that I am not saying that there is no market for Foundrys new products. There is a large distinction between edge and enterprise routers and Core routers running core Internet protocols (BGP, etc.) This looks like a very interesting set of announcements for large enterprises, and I hope that they are succesful. However, the core is where Foundry claims these products are targeted.

THe differences between core routers and class 5 are not the complexity of the features supported. I agree that the task of Class 5s is argueably just as complex as that of routers. Perhaps it is even more complex. It is not complexity per se, but the massive amount of undocumented function that has to be supported that is the issue.

New features were added to class 5s in an orderly manner. New services were added in an orderly manner. The netowrk was desinged around predictability and managing the introducion of new traffic and services (dial up Internet was one exception, and the system broke when Erlang tables went out the window).

The Internet is just the opposite. It was not designed to handle any particular service, services and load were added as desired by the network users without changes to the network, and there was little in the architecture and standards to handle the issues that core routers faced as the system scaled.

As a result, much of the function was added a piece at a time to solve specific problems that arose as the Internet grew. These functions were never addressed in standards as router vendors (i.e. Cisco) considered them a barrier to entry. Why introduce changes in the standards if you can let your compeitors routers crash when their standard BGP can't handle network issues?

To make a core router that works properly, you have to duplicate a thousand "hacks" to the standard BGP, things that Cisco added over a decade of fixing problems. Juniper did this over a several year period using a combination of very experienced ex-Cisco programmers and architects, plus a lot of trial and error in their customers labs and networks. They never underestimated or understated the size of the task.

Almost all of the basic standardized code that Foundry has added is available in open source. In order for it to operate in the Internet core, however, the "thousand hacks" that I refered to have to be added, both by hiring architects with experience and by trial and error in customer network trials.

If Foundry came out with a story about how they had hired certain specific people, were working with specific ISPs who wanted a third vendor, and had spent X amount of time in a customer network, then I might get excited. To believe that Foundry has done this without some key hiring (the kind of hiring for which you issue press releases), years of work, and a year of customer trials? Well, I have a few bridges to sell you. The most significant part of their announcement was the absense of any customer support.

On the other hand, I agree that this is not an advantage that will last forever. Outside of Cisco and Juniper, who live off of this barrier to entry, most people wish we could replace current network control plane protocols with something more scaleable without all of the hacks. The Internet would certainly be better off. IMO at some point the current network potocols will break, and that will be the time where true competition will errupt. That's what happened with DWDM... there was no choice.
Until then, Cisco and Juniper will keep making modifications to keep the dinasaur alive as long as possible. Carriers are wary of making wholesale changes and will keep using what works until it breaks.

TO another point...Aside from the lack of a software and customer story, one also has to look at the price comparisons in the announcement. In some cases, they are comparing apples to oranges (Ethenet ports to SONET ports). In other cases where the comparisons are legit, they are comparing price to price, not cost to cost. If Foundry makes a line card for $20K and sells it for $25K, and Cisco makes the same line card for $20K and sells it for $100K, does this mean that Cisco sit back and watch Foundry take business? On these high end routers, Cisco has a huge margin to work with. IMO, however, they will not need to compete until Foundry has a legitimate software story and customers indicate that they a hungry for a third core router vendor.

Reply | Post Message | MESSAGES LIST | START A BOARD

spelurker 12/5/2012 | 3:22:56 AM

re: Foundry Strikes at the Core > long explanation by douggreen

ABSOLUTELY. I've personally seen ALL of this in practice.

I think I take exception to the expression "hacks", though. What it really comes down to is that the BGP, etc. specifications talk about is almost entirely protocol related. They do not address how one marries this to a forwarding device, how one manages large tables, what the edge conditions are which will cause large amounts of data to change in a small period of time.

Essentially, the problem is that the internet was never designed, it grew organically. And BGP is essentially a "best guess" at a control protocol based on experience. It is really difficult to model "the internet" as a complete system, because nobody completely understands it. (So how does one control it efficiently?) This is an extreme case of the "distributed system" problem. One can only really build a stable distributed system if one controls all of the nodes. For the internet, pandora opened that box long ago, and we are left with only hope.

For example: There are X billion people in the world, and Y million devices plugged into the network. How do I distribute more IPv4 addresses to the network without running out, while waiting for IPv6 to be adopted? How many routes does that mean my router needs to support? What happens if some rogue network element starts spitting bad information into my route table? How do I detect it? The list goes on and on, and the answers are not guaranteed to be documented, or even correct.

Reply | Post Message | MESSAGES LIST | START A BOARD

sigint 12/5/2012 | 3:22:56 AM

re: Foundry Strikes at the Core tmc1, replying to Optoslob:
You chip economics are great but what if the chip really doesn't work well, is full of bugs or missing needed features (like most of the off the shelf NPUs). It really doesn't matter how cheap it is.
__________________________________________________
tmc1,
IMO, it would be difficult to beat chip vendors on the actual science of silicon design. That said, a silicon vendor is often short of system design talent. I think that has changed during the downturn where chip companies could take their pick of talent during the blood-bath. What you say is probably true even today, but may change as the chips currently being designed hit the market.

Reply | Post Message | MESSAGES LIST | START A BOARD

douggreen 12/5/2012 | 3:22:55 AM

re: Foundry Strikes at the Core spelurker said "I take exception to the expression "hacks"

OK, lets just say that IOS and Junos have to include a very large number of undocumented "fixes" to the inadequacies of documented protocols.

To those who don't want to read my "long explaination", let me put it in simple terms:

Duplicating class 5 function requires duplicating a very complex design. Duplicating IOS version of BGP is like trying to duplicate exactly the complexities of a train wreck. The train wreck is much more difficult to copy.

This is NOT a knock on Cisco...their code is a result of the inadeqecies of the protocol and the unanticipated scale of the Internet, not incompetence.

Reply | Post Message | MESSAGES LIST | START A BOARD

rjmcmahon 12/5/2012 | 3:22:55 AM

re: Foundry Strikes at the Core Doug,

I agree with your synopsis, with a few caveates or clarifications as noted.

THe issue is keeping up with millions of network routes in a dynamic environment within a network architecture that allows routing information to change faster than the network can disseminate that information.

I'd say "forwarding rules" in the place of network routes here. Packet forwarding seems to have evolved much and now it's based on many things beyond the traditional IP route.

Also, packet networks do converge. Control theory would suggest that it's impossible for the forwarding rules to converge faster then the feedback loops send their signals. The "network" has to disseminate the updates quickly so the rules can stabilize. Hence, a challenge becomes figuring out what the best feedback signals really are. Sometimes it may be a user configuration event. Sometimes it may be noticing a host transmitting a stream of packets. Sometimes it may be a route update from a peer. Sometimes it may be noticing a rogue host attempting to poison the network. Figuring this out requires a lot of real world experience.

This knowledge has to be "institutionalized" in some way. The solutions aren't kept in the minds of a few individuals. They probably can't be found in a traditional documents. It seems a combination of hardware and software logic is the mechanism to hold and realize this knowledge.

In addition, information exchange in the control plane is exposed to problems within the data forwarding plane. Add to that the fact that both the control plane and data forwarding must account for hostile actions.

The whole thing reminds me of combining the Traveling Salesman's Problem with the Byzantine General's Problem. It's amazes me that the system really works.

PS. I think the phone guys did one hell of a job with the PSTN. It would be impossible to advance communications infrastructure without their work. Standing on the shoulders of giants definitely applies.

So kudos to the many engineers across the globe for advancing our communications infrastructure and, in turn, making our world a better place.

Reply | Post Message | MESSAGES LIST | START A BOARD

paolo.franzoi 12/5/2012 | 3:22:55 AM

re: Foundry Strikes at the Core
I think this portion of this thread is what leads me to believe that advanced services over the public internet with guaranteed QoS is a pipedream.

Private IP networks seem like the thing to do for those.

seven

Reply | Post Message | MESSAGES LIST | START A BOARD

optoslob 12/5/2012 | 3:22:54 AM

re: Foundry Strikes at the Core Reply to Siginit
I know many people that have tried to do multiple products on a wafer but I have never seen anyone go to production with that flow. The main problems that I see are
1) for standard sawing all die will need to have at least one axis of the same length
2) all the chips need to fit within one stepper frame
3) when one chip has problems you usually dont want to be inadvertently changing the other working chips (this can happen when dummy layers get generated on the new tape out)
4) If you reduce the stepper field to be just the number of die that you want than 5*chip A and 1* chip B 2* chip C than you will have low stepper utilization for which the fab will charge extra.

5) Directly interconnecting the working die is basically the same as building one VERY big chip so one bad section and you scrap the whole system
It is possible to select working die and interconnect multiple devices by depositing metal on top of the chip over-coatlayer but this is very uncommon.

6) getting rid of the heat is one of the biggest problems with chips these days, so adding more functions in a smaller area only makes the heat problem worse. Not having a package will really cause heat problems.

ALTERNATIVE

There is however another way to do what you want it involves putting as many mask layers as possible onto a single mask and shuttering the stepper. lets say 4 layers are on one mask, You print one quadrant for the first layer while shuttering the other 3 and so on for the rest of the layers. this process can reduce mask costs to one quarter or even 1/8. Stepper utilization is clearly very low.

The advantage is that you only have type of chip per waferso all the back-end packaging / testing issues are eliminated.

Hope this helps
Optoslob

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 5 / 13 > >>