Subject: Re: Support for multicast in the ForCES protocol

From: "Putzolu, David" <[email-masked]>
Date: Fri, 21 Nov 2003 12:04:32 -0800

[chair hat off]
Jamal Hadi Salim wrote>
> I dont think it is a startup challenge issue only. The 
> challenge applies
> to all applications that build state based on packet arrival 
> events. And there are many.
> Think of an IDS under a DOS. Or a flow tracking firewall system.
> 100s of FEs, millions of flows (say a 100K new ones per second).
> You certainly wanna distribute that info to the FEs.
> Unless you wanna rule out such apps for ForCES.

IDS and flow tracking firewall is a specialized and challenging
application, and firewalls and load balancers are often architected
differently from routers - is the CE:FE protocol in the 
ForCES architecture the right solution for such an app?  

Tracking flow state in a coherent fashion across blades can require
updating state as often as once/packet in each flow. Using ForCES,
that would require an event to the CE, followed by the
CE creating and broadcasting a flow update message
to every FE - all occurring every time a TCP SYN, SYNACK,
or FIN (at least) is received.  Wouldn't a FE:FE protocol
be a much better fit for this class of applications?

Cheers,
David

---

From: Alan DeKok <[email-masked]>
Date: Fri, 21 Nov 2003 15:59:37 -0500

> be a much better fit for this class of applications?

  In many cases, yes.  In addition, FE's may have self-programming
abilities, to keep track of flows, because it's very easy to do.  In
contrast, IDS updates occur much less often.

  One of the problems I've seen is that people confuse flow management
with IDS or packet filter rules.  They're orthogonal, and shouldn't be
discussed at the same time.  e.g. "We support 1000 IDS rules, and
100,000 flows, so that means we support 100,000,000 rules!"

  Such statements are marketing propoganda.  The two data sets are
independent, and cannot be combined, or compared.  No one would claim
that a router supports 100,000,000 ACL rules, because it allows 1000
ACL's to be applied to 100,000 flows.

  IDS and packet filter rules are the application of a small set of
complex rules to a large number of packets.

  TCP flow management is the application of a large set of simple rules
to a large number of packets.

  The confusion arises because many IDS rules are only useful when
applied across packet boundaries (i.e. to flows, not individual
packets).  This means keeping track of flows, and the sub-part of the
IDS rule that should be used to filter the current packet.  But it does
NOT mean creating a new "IDS rule" for every flow.

  So to bring the subject back to the original topic, I don't see IDS
rules or packet filter rules being subject to high update rates: seconds
per update.  I do see packet flow management requiring high update
rates: thousands to millions of updates per second.

  Are there use cases which *require* inter-FE or CE-FE communication
for flow management?

  Alan DeKok.

---

From: Niranjan Vaidya <[email-masked]>
Date: Fri, 21 Nov 2003 17:45:24 -0500

["Putzolu, David" wrote:]

>>be a much better fit for this class of applications?

["Alan DeKok" wrote:]

>   Are there use cases which *require* inter-FE or CE-FE communication

Consider a scenario where one FE is a hot standby for
another and needs to maintain up-to-date state for a
flow (or session or SA) in order to enable a hitless
switchover.

In many products today, this is enabled via a vendor
proprietary solution. Is there interest in covering
it under Forces? An argument in favor would be that
each FE must implement Forces and from a vendor's
perspective, FE-FE communication would be simplified
by using pre-existing building blocks already defined
for CE-FE communication.

Regards,
Niranjan

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 22 Nov 2003 10:42:48 -0500

On Fri, 2003-11-21 at 15:04, Putzolu, David wrote:
> application,

Challenging is a good word ;->

> and firewalls and load balancers are often architected
> differently from routers
>
> - is the CE:FE protocol in the

I just gave those two as an example and i think they are valid.
The general class of the problem is events that are caused by packet
arrivals (or maybe even timers) that require distributed state updates.
I know some routers(since it seems thats the operative word
unfortunately) or router architectures that use LPM cache entries or
adjacencies to speed up lookups (i.e you have a FIB which is considered
the slow path and some form of cache as the fast path). Some people may
have given up those architectures, they are however very useful IMO
because they allow you to associate additional state to the simple FIB
entry added either at the beggining of the FIB + (mostly)srcIP tuple
being hit or adjacency being created. I dont want to sell their virtue
or argue their value; suffice it is to say they exist.
Now that i have used the operative word "router" - would those serve as
good example?
In regards to architectures being different:
I think that boundaries are greying - in particular at the edges of the
network. I havent seen a router(at least in my contact) in the last 2-3
years which didnt have some firewalling capability built in.
In fact quiet a few that i have seen are also adding loadbalancing
capability; pick a $10 router from foundry (not sure how commodity you
wanted to get) and you will see what i am talking about. I suspect the
trend is gonna head that way. And i suspect these devices are gonna
scale even further by going into chasis and chasis going further into
racks. Would you want these devices selling for $50 a chasis out
of Taiwan be able to use Forces? I want them to.

> or FIN (at least) is received.

Did you forget RST? ;-> just kidding.
You would have to do a few smart things, but this is the wrong place to
discuss that.

> Wouldn't a FE:FE protocol

If you are multicast capable, it doesnt matter: Use CE-FE events.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 22 Nov 2003 16:57:03 -0500

In most lookup cache, flow processing, or RSVP architectures I know of, at
most two (and typically one) FE would need to be updated when there is a
change.  Hence, I am unclear as to why this is being suggested as a reason
for multicast.

Yours,
Joel M. halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 22 Nov 2003 21:33:08 -0500

The discussion digressed. Someone claimed that multicast would be useful
only if you did have a lot of updates per unit of time (of course i have
never thought of this as the reason why multicast would be useful;->).
BGP route updates were pointed out. Someone else claimed BGP updates
were only meaningful at startup. Someone else suggest events equivalent
to flooding would be useful etc ......
I think you could do clever things like breaking down the event to be
per few FEs and hierachical, but thats besides the point.

cheers,
jamal