Is Hyperchip Hype?
Peter Galbraith writes "There was an interview on CBC (here in Canada) last evening about
Hyperchip, a Montreal-based
company that are working on a new type of router that would scale up 1000 times in traffic (so wouldn't be obsolete in less than a year) and would pass packets to their destination in a few hops instead of a dozen or more. Any experts out there think it's hype? Or real?"
The explanation on Hyperchip's "technology" page is pretty thin, but considering they just raised $70 million, I hope they've given more convincing details to their investors.
Cisco and Juniper can only (currently) route in gigabit speeds.
Other competitors that they will have to deal with: Pluris, IronBridge Networks and Charlotte's Web Networks .
The same thing is happening on this side of the border. LaurelNetworks is another super-startup company, with a lot of capital, with their guns aimed at the "big boys" of network hardware (Cisco, Juniper, etc.). I did some work with Laurel, and even some work with a micro-startup networking company, BlueWave Networks.
:)
I don't think that there's any hoaxing at all going on here. They're legitimate players with some heavy capital backing them. They also have great engineers and some good technology. It may not be enough, however. What it's going to come down to (IMHO) is the willingness of big ISPs and carriers to adopt technology from a new vendor.
Cisco may not have the best equipment, but everyone and their dog worth their salt in this game knows IOS and how to admin it. You can't say the same of any of the new vendor's products.
We've moved beyond the days of "great ideas" and "great products." Internet routing is a mature market in which the biggest obstacle is now overcome the inertia of the entrenched players.
The anology reminds me of Linux vs. MS, but then again, what doesn't?
From Thier site:
.... and that a packet originates in Boston and is transmitted in red light to the next node, if the light isn't the color for that node, So if red was Richmond, NY and Washington would reflect the red light down the line until it gets to Richmond. This way NY and WAS don't have to convert the signal which saves a lot of time and work. Also this allows Boston to talk to Richmond as 1 hop as far as the software is concerned. Similarly a packet transmitted in Amber light might go all the way to Atlanta before being converted to Electrons.
Accelerating the war are the recent advances in ultra-long-haul optics and optical switches, which are making it practical for routers to place packets on destination-based wavelengths that can take them as close as possible to their final destination in the core, thus eliminating intermediate routing hops and unnecessary O-E-O conversions.
I read this as meaning that you have a strand of fiber that runs from say for example Boston, to NY to Washington to Richmond to Charlotte to Atlanta to
Sounds like a good idea to me since it should work on existing fiber. The real question is how hard and expensive is it to start with two nodes and grow from there.
Slashdot is an anagram for Has Dolts, and I am Dolt number 468543
Couple of things...
/24 in class B space, without advertising the /16 also, so the route gets nuked at a border router, as quite a few providers filter based on classfull boundries, or people just not understanding how a traceroute even works, and demanding to speak to a 'routing guru' because their traceroute dies after a certain point due to an ACL (access control list), so they naturally think the web server/mail server, etc they are going too is down, even though it is not.).
1. 90% of the time when you call a large internet service provider, you speak to their frontline support, who address their level 2 support (etc) as 'routing engineers', consider how many people must call them and complain about problems (90% of which are probably caused by stupid things like them advertising a
2. As someone pointed out, number of hops != latency, etc. Most people who are just starting their quest for knowledge in this field tend to confuse the two unfortunately.
Now, while in an ideal network, 99% of things will be done at layer 2, thereby making the total hopcount in your traceroute lower (if your traffic is going through an ATM switch who doesn't know about/care about layer 3 information in an ATM cell, it will obviously not show up as a hop in your trace). The hopcount your traceroute shows doesn't matter, the simple fact that all that has to be done is the header of the ATM cell (the first 5 bytes) is read, and then the cell is forwarded to its proper destination (similar for ethernet, using cut-through switching, etc) doing switching at layer 2, vs. having to read the IP packet's headers to find the destination will provide a noticible decrease in latency in most situations.
You are however correct in that Cisco has many features out there that will greatly increase performance for people. Mind you, there aren't any official 3rd party benchmarks against this (the company the article is referring too) company's products, so we don't know if they are something to laugh at, or really are better then whats out there currently (although I am voting for the laughing part).
Also, in regards to BGP, (heh btw it has quite a bit of overhead, since it uses TCP), while it is pretty much the only good choice for an EGP (external gateway protocol), you will still need an IGP such as OSPF, etc unless you intend to have your router(s) have BGP sessions with the IP's of other routers known via directly connected (or static routes), which would be stupid (except for some situations using static routes in a very small network). Its not like you setup a BGP session with another router, and it 'magically' works, there is quite a bit of traffic engineering involved (how much is dependent on how big your network is), and cooperation among internet service providers (i.e. to set the localpref that is distributed to your IBGP mesh based on certain communities received from a peer, or the other way around, so people can control the path traffic goes back into their network in a better way then padding the route (i.e. adding more AS's to the AS_PATH which chances are wont give you the desired results), or other methods).