x
<<   <   Page 2 / 9   >   >>
rtg_dude 12/5/2012 | 12:15:33 AM
re: Caspian Comes Out Ross Callon, RFC1925: "With sufficient thrust, pigs fly just fine"

Do people ever learn? We've been there in mid 90's, when Cisco came with NetFlow Switching (not to confuse with NetFlow stats), same promises - better QoS, faster lookup, etc. Result - it does NOT scale. One more time - it does NOT scale. Way too many flows in the Internet. We realized that we need to bite the bullet and implement line rate FIB lookup for each packet. We can do it faster than any hash tables lookup today, no problem.

Router architecture 101 - the amount of state the router has to maintain MUST NOT depend on the amount of traffic going through it.

You can stretch this a bit at the edge, where the number of flows is somewhat limited. In the core - forget about it. As skeptic said - DoS attacks are a huge problem here - picture a DDoS using millions of infected hosts and servers, huge number of new flows, overloading the flow table and keeping valid new flows out.

RSVP-like mechanism in the network, and I'm afraid it is on a per-flow basis too. We have been there with IntServ in the IETF. Result - it does NOT scale. Once more - it does NOT scale. That's why we moved to DiffServ.

So now we have at least two major architectural mistakes productized, and crystallized in silicon.

This is really an example of how VCs used to spend money just a while back. Guys, you should have talked to someone with at least a tiny bit of clue. Kiss your money good bye.

rtg_dude
madkill01 12/5/2012 | 12:15:32 AM
re: Caspian Comes Out >You can stretch this a bit at the edge, where the >number of flows is somewhat limited. In the core - >forget about it. As skeptic said - DoS attacks are a >huge problem here - picture a DDoS using millions of >infected hosts and servers, huge number of new >flows, overloading the flow table and keeping valid >new flows out.

Although I don't support the flow based architecture but technically speaking, flow based model is not susceptible to DoS/DDoS attacks. There are very simplisitic architectural changes (which are common sense) that are made within such systems to circumvent the possibility of running out of flows. i.e. you simulate the ability to have never ending space similar to the concept of SYN cookes by DJ bernstien if anyones fimiliar with it. Enuf said, getting back to the topic. Although much was expected of Caspian and Dr. Lawrence, I think this company seems to be leaning towards a disaster unless the pull out a joker from their deck and somehow offer some real value to the carriers....
BobbyMax 12/5/2012 | 12:15:32 AM
re: Caspian Comes Out It is unfortunate that Caspian is trying to make its ineffective and unscientific thinking by hiding in a stealth bomber. This simply does not work. First I must note that Flow Based is roting is based on heristic considerations. Therefore, it is difficult to construct a verifiable routing algorithm. Because of the impricise nature of fows. scalability would always be a problem. It is not possible to find very precisely the set of routes that minimize delay.

These routers are nothing real but based on gimmic. Its performance cannot be trusted.
lastofthebohicans 12/5/2012 | 12:15:27 AM
re: Caspian Comes Out There must be only a skeleton crew remaining in their NC location, the last vestiges of the former Nortel/BNR team. Any updates?

As to Aperio (sp?): Infinite scalability == infinite hogwash. You could get away with such swagger during the bubble days, but not now ... how does one manage and provision an "infinitely scalable" network? Where's the beef? ... TL1/SNMP on the embedded side, LDAP/XML/CORBA around it? Inquiring minds want to know ...

-lotb
Kevin Mitchell 12/5/2012 | 12:15:24 AM
re: Caspian Comes Out Wow, new messages from Caspian! Beforehand, they pushed Dr Larry Roberts, god of all things IP, instead of products. Back in late 2000 they started touring with Larry Roberts as if that alone is enough for company success (perhaps it was back then and they could have pulled off an IPO if the bubble lasted another year).

I don't think this company can make it. Flow-based routing sounds fancy, but not made for this world. Seems to run as company propritary alternative to IPv6, no? I'm not an engineer, but it doesn't pass the sniff test for me. Who likes this technology? Am I full of it?

rtg_dude 12/5/2012 | 12:15:24 AM
re: Caspian Comes Out madkill01:

There are very simplisitic architectural changes (which are common sense) that are made within such systems to circumvent the possibility of running out of flows. i.e. you simulate the ability to have never ending space similar to the concept of SYN cookes by DJ bernstien if anyones fimiliar with it.


Please educate us. Keep in mind that routers cannot assume that the see all packets in the flow, because of ECMP.

rtg_dude
random_task 12/5/2012 | 12:15:20 AM
re: Caspian Comes Out #!/usr/bin/perl
# Generate a million flows with 100
# packets per flow.
for ( $i = 0 ; $i < 100 ; $i ++ ){
$SIP = 64.225.154.175;
$DIP = 66.118.156.122;
$SP = 0x6969;
$DP = 0x9696;
for ( 0...1000000 ) {
GEN_PACKET ( $SIP, $DIP, $SP, $DP );
$DIP = INCREMENT_QUAD ( $DIP );
}
}

sub GEN_PACKET { print "THIS IS IMPOSSIBLE!!!\n"}
sub INCREMENT_QUAD { print "I don't know what I am talking about\n"}
Steve Saunders 12/5/2012 | 12:15:19 AM
re: Caspian Comes Out If your account was deleted how did you manage to post this message?
tspoon 12/5/2012 | 12:15:19 AM
re: Caspian Comes Out This site disabled my account because they do not want to be exposed, or look silly. My point was that Caspian is playing the lets re-spin the crap game.

Grow up LR
TheNet 12/5/2012 | 12:15:18 AM
re: Caspian Comes Out rtg_dude,

You wrote: "RSVP-like mechanism in the network, and I'm afraid it is on a per-flow basis too. We have been there with IntServ in the IETF. Result - it does NOT scale. Once more - it does NOT scale. That's why we moved to DiffServ."

1) Anybody who thinks that DiffServ is going to solve QOS problems is dreaming. QOS is about Reserving Resources. A good analogy to DiffServ: it's about layered Best Effort clouds. Best Effort is not about QOS. Even if you implement policing functions around the edge, you won't be able to predict all the traffic patterns happening inside the individual clouds... and yes you will have "storms" and yes you won't be able to guarantee QOS.

Another interesting analogy is the parallel one can make with the road system. Even though we have policing functions (traffic lights, stop signs, cops, traffic report etc.), the only way to guarantee QOS across the road system is to RESERVE RESOURCES such as lanes. And please do not tell me that chucking away packets that are not "high priority" in case of congestion will solve the problem.

2) Wake up guys: Best Effort Internet is NOT where the money is. Look at what's making money in this industry: leased lines (reserved resources), virtual lines (ATM/FR) (reserved resources).

3) Don't get me wrong: Best Effort Internet is here to stay. Don't be fooled: it is subsidized by revenue generating services though.

4) The way to build big networks is by applying scaling functions such as aggregation, control & switching. What the Caspian guys are doing with their micro-flow based architecture for a Core Router is fundamentally flawed. Micro-flows should be aggregated before hitting the Core Router. The Core Router should have reserved channels through different locations around the network. The aggregates must be policed and admission control must be performed. [...]

The way to go for QOS is more control & resource reservations. And please note I didn't say RSVP.

The architecture of the venerable PSTN will come back.

PS: I do not work for Caspian, nor cisco.
<<   <   Page 2 / 9   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE