Re: Pipeline problem is resolved (fwd)

Karl Denninger (karl@Mcs.Net)
Fri, 4 Apr 1997 13:53:37 -0600

On Fri, Apr 04, 1997 at 11:20:26AM -0800, Kevin Smith wrote:
> At 12:27 AM 4/4/97 -0500, you wrote:
> >
> >> >On a side note I though Livingston was going to support BACP, guess that
> >> >must have fallen by the wayside as I know telling the P75 to use BACP
> >> >dosen't work with the PM3..
> >>
> >> We were/are considering it. But it has been in extremely low demand, so
> >> it never gets scheduled.
> >
> >
> >Well since Ascend now supports it, and as much as you probably hate to
> >admit it, there are a LOT of Pipelines floating around. So since I know
> >you have no intention of supporting MP+, supporting BACP would let the
> >Pipeline and the PMx interoperate much better. I would sure love to see
> >it so there is one vote.. :)
>
> Also look at the list of vendors besides Ascend/Cisco that do support BACP,
> there *are* plenty of boxes out there to work with....
>
> Kevin Smith Updated Service and Support
> Senior Technical Support Engineer Resources are now at:
> Customer Satisfaction
> Ascend Communications http://www.ascend.com/service

That doesn't make it any less braindead.

It is trivially simple to determine the load on a sync line. ANY sync line.
Just count how many flags are being sent (required to be transmitted any time
an HDLC line is not fully utilized) and if you're not getting ANY the line
is at capacity.

You can self-calibrate this as well. Since you know how many flags you
*can* get in a unit of time (due to the fact that you know how many bits per
second the line is clocking and you also must know the HDLC requirements
since you're DOING it), you can now set a percentage of utilization at which
you consider the line "full" and which mandates a channel be added. This
can then be externalized in the form of a parameter which says "at X%
capacity, add a channel, and at Y% of combined capacity, drop one".
Some basic sanity checks (ie: Y must be <= 1/2X to prevent constant
oscillation) and you're done.

Note that this works WITHOUT any BACP nonsense, and furthermore, it works
regardless of whether you're the TRANSMITTER or RECEIVER of the data stream.

Some folks, notably SGI, figured this one out *YEARS* ago in their ISDN
connectivity implementations.

I have brought this to the attention of ASCEND and several other vendors
multiple times.

ASCEND has ignored these facts for well over a year.

Adding protocol layers on top of a system to perform a job which is
trivially able to be accomplished without doing so is, in my opinion,
braindead and shows a lack of operational thinking processes within the
organization that does so. The only *other* possible argument for this
behavior is to make it "harder" to cleanly interoperate with the maximum
number of devices on the other side. That's a good reason NOT to buy
or recommend such a vendor's products.

BACP has its place (notably in async environments where you *can't*
determine how "full" the line is).

This isn't one of them.

To *ALL* the ISDN vendors out there -- do this one right. Its not difficult.

--

-- 
Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, http://www.mcs.net/
Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines!
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal