RE: draft-morrow-filter-caps-00 comments

["Barry Raveendran Greene" <bgreene@cisco.com>]

> > process packets, that CPU cycles will be spent on any 
> packet - whether 
> > it is a data plane packet of a management/control plane 
> packet. So how 
> > do you expect complainance with "no impact on device 
> > CPU/manage/concole" when all you have is a CPU once you 
> saturate the 
> > cycles, you have to sacrifices something. If you set the 
> time slices 
> > to allow the console to always have a slice, then you are 
> taking away 
> > time slices from something else in the CPU processing queue 
> > (forwarding, routing protocols, management, etc.).
> >
> 
> I also agree that this requires more thought :)

Perhaps playing around with the ability for the operator to make the choice.
For example, we added the 'process-max-time' to allow an operator to choose
to only allow a process x time in the process queue. So "process-max-time
200" would only allow a process in for 200 ms - round robining through the
processes - allow for the console commands to get processed. So someone on
the console would get a responsive console with the CPU at 99%/99% - all
under a DOS attack. Are other processes working OK? It depends. 

This is one approach to managing the CPU cycles under a saturation incident
(i.e. DOS attack being one type of incident). With the vast majority of
routers out there being CPU based, more guidance for what funcationaly to
code would be helpful.