On 10/22/07, Henning Brauer <lists-openbsd@bsws.de> wrote:
quoted text
>
> * Tony Sarendal <tony@polarcap.org> [2007-10-22 14:59]:
> > On 10/22/07, Henning Brauer <lists-openbsd@bsws.de> wrote:
> > > * Tony Sarendal <tony@polarcap.org> [2007-10-22 01:19]:
> > > > On 10/21/07, Henning Brauer <lists-openbsd@bsws.de> 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