[Xorp-users] SNMP & QoS

[Aidan Walton]

Thanks Mark,

Well it just goes to show, never assume anything. However it seems I
wasn't a million miles off the mark. I imagine I can use other packet
scheduling techniques that are workable with my kernel independently of
the control plane, so for traffic management I still have options.

Back to the work you just did though. Can I work out easily what tasks
you consider are critical in the process schedule by looking at this
code. I have memories of ARP on a Ethernet/MAN segment being a killer of
control plane code if not rate limited. Is this the sort of thing that
can now be achieved? Also does XORP currently have any control over how
protocol traffic gets inserted onto outgoing interfaces? As I remember
another historical problem was neighbour sessions dropping (BGP & IGP)
if control plane traffic could not be prioritised during heavy data
plane loads. I (once again) assume the FEA has some control of how
control traffic gets inserted into the kernel forwarding plane, but I
was under the impression that the kernel forwarding plane was
independent of XORP and its abstraction layers, so how do we prioritise
control plane traffic as it traverses the kernel forwarding plane? I
suspect my answer is in my first paragraph, is this correct?

Cheers
Aidan


On Wed, 2006-08-16 at 09:46 +0100, Mark Handley wrote:
> On 8/16/06, Aidan Walton <aidan at wires3.net> wrote:
> > 1. I recently watched CVS commits of round_robin.cc, round_robin.hh and
> > was wondering how this QoS capability gets enabled in the configuration
> > and if it is now active if I compile the latest CVS snapshot. (I assume
> > this is QoS and not a round robin algorithm for some other function
> > rather than traffic management)
> 
> round_robin is not a packet scheduler, but part of the new XORP
> internal task scheduler.
> 
> Previously within each XORP process we had timers and selectors
> (sockets), and background tasks used zero-second timers.  Under high
> levels of load, we could get backlogged and not perform essential
> timers or other functions until it was too late.
> 
> The new task scheduler has priority levels for timers, sockets, and
> background tasks, and then for tasks within each priority level we do
> weighted round robin scheduling.  This allows us to prioritise
> important timers or sockets, and to schedule some tasks more than
> others without starving any (as would be the case with pure
> priorities).
> 
> The aim is that this should make XORP (especially XORP BGP) more
> robust under overload conditions.  But it's early days yet - I only
> wrote the new scheduler last week - and no doubt we'll have to do some
> tuning to get this right.
> 
> So, sorry, not QoS.  That would be part of the forwarding path, and
> XORP (so far) focusses on the control plane leaving forwarding to the
> kernel.
> 
>  - Mark