[nsp] MLPPP & Cisco

[warner at cats.ucsc.edu]

> I also wouldn't object to performance guidelines if anybody has...

Given all the crys of anguish and dire warnings we've heard about
MLPPP, it sure seemed like a major non-event to us.  We gave this
to an engineer in training and it just happened.  

We are combining a pair of T-1s (how much the users can afford)
using back to back 2600XM routers.  The target audience is 
"student residential" which means they try hard to move as much
data as they can all the time.  The CPU load from doing this is
at:

 http://newnoc.ucsc.edu/nrg/net/router/cpu/uinn-resnet-g/uinn-resnet-g-cpu.cgi

the corresponding data flow is at:

 http://newnoc.ucsc.edu/nrg/net/router/utilization/uinn-resnet-g/uinn-resnet-g-_MLPPP_aggregate_link.cgi

I would feel comfortable bonding 4 T-1s this way.  I might go as high
as five.

One thing that has not been mentioned about MLPPP is that there
is an option to slice up individual packets and spray the pieces
across your collection of T-1s for reassembly at the far side.
We do not use this option and we imagine that it would chew
up the CPU a lot more than the whole packet varient of MLPPP.
It does not seem like the slice-dice option would be useful
above ISDN BRI speed.

Our T-1s are local.  They have low transit time and therefore
low skew.  Someone with greater transit time or more skew might
need more buffering than we do, so they could in principle see
a different result with the same hardware.  In practice, I don't
think this would be a problem.