On 10/22/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > > * Tony Sarendal <[EMAIL PROTECTED]> [2007-10-22 14:59]: > > On 10/22/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > > > * Tony Sarendal <[EMAIL PROTECTED]> [2007-10-22 01:19]: > > > > On 10/21/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > > > > > well, you can go stateful up to a certain point and handle stuff > above > > > > > stateless (better than dropping), like > > > > > > > > > > pass out on X from $foo > > > > > pass in on X to $foo > > > > > pass out on X from $foo keep state(max 10000) > > > > To design a reliable IP network I would need the devices to be able > to > > > > handle > > > > the desired pps rate even when that state limit is exceeded. > > > so? where is the contradiction here? > > No contradiction. If the requirement is to be wirespeed the forwarding > > performance under ideal conditions is not relevant. > > with the amount of states you can handle, I don't think it is a limit > very relevant in practice. Or, in other words, if you need to handle so > many more flows than we can handle statefully, you are at a point where > you cannot realisticly use a commodity hardware router any more. > > > > Many routing devices have over the years achieved good performance by > > > > different flow caching > > > > methods, we have over the years also learnt that this is a bad thing > in > > > > uncontrolled environments > > > > like the Internet. > > > no, that is entirely bullshit, sorry. > > > > > > if flow cahcing allows your device to work more efficient in the usual > > > case, hey, excellent, you would be dumb to not use it. > > > > > > this does NOT save you from either leaving enough headroom that you > can > > > heandle the packet rate when exceeding your state limit or at least > > > know about and live with the limitation. > > A Cisco6509 SUPA1/MSFC2 could do around 10Mpps under normal conditions, > > but not even 500kpps when flow count exceeded what it could handle > > in hardware. Good boxes for the internal network, horrible for the > > datacenter or internet core/edge. > > and I bet I can make up a 10 or maybe 100 Kpps stream that makes it fall > over. > > > > A reliable IP router is wirespeed and stateless. There is no getting > > > around > > > > that. > > > > > > oh really. > > > I say it is bullshit > > Are you officially stating that the added complexity of stateful > forwarding > > does not increase the likelyhood of unpredictable behaviour ? > > yes. the state tracking is not THAT difficult and very very very mature. > > > > there is no single wirespeed in all circumstances router on the > market, > > > not even for fast ethernet. that is a marketing gag. a 10 MBit/s > stream > > > of correctly and purposefully craftet packets brings each and every > > > router you can buy to its knees. if it works like an OpenBSD machine > > > with stateful filters which prefers established states in the overload > > > case, it doesn't suffer as badly as the stateless ones. > > Something as simple as being able to forward packets independently > > of the source/destination pattern and protocol hardly qualifies as > > the specific/unknown case where you can make a 80Mpps per line card > > CRS-1's not even forward 10Mbps. > > i can't parse what you wanna say here. > > > OpenBSD once shipped with a remote root compromise, this was addressed. > > When we find new scenarios that can prevent the routers from performing > > as expected we try to address that. There will always be unknown corner > > cases showing up, and that we need to handle. > > which is totally independent from specific implementations. this is > true for each and every piece of hard & software available. > > > No need to get aggressive, Henning. > > I'm not aggressive :) > > > I don't agree with you. I say that a stateless device in general is more > > reliable than a stateful one. > > and I say that is totally poop. It is a marketing lie.
I didn't get that opinion from marketing. No matter, we disagree, lets leave it at that. /Tony
