Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Inter operability & BACP,DBA,BOD et. al.
On Tue, Sep 16, 1997 at 11:53:27AM -0700, Matt Holdrege wrote:
> At 11:44 AM 9/16/97 -0700, James Johnson wrote:
> >At 08.37 16/09/97 -0500, ascend@digistar.com wrote:
> >>
> >>> 2) The call is never placed for what ever reason.
> >>
> >>The pipeline never tries to initiate the 2nd channel...
> >
> >Thanks for the extra info. I came to this same conslusion from looking at
> >my logs.
> >
> >Does Ascend have plans to fix this problem? Or is the general solution to
> >wait for BACP to become more prevalent?
>
> I don't see the problem. We came up with a protocol that works called MP+.
> It's an RFC. The IETF came out with a similar standards track RFC called
> BACP which is in every major product (about 70 routers and TA's) except
> Livingston.
>
> Matt Holdrege - http://www.ascend.com - matt@ascend.com
And I could publish "stupid router tricks" as an RFC too.
There is a difference between a protocol that serves a purpose, and one
which does not and is simply overhead.
BACP and MP+ are overhead and serve NO rational purpose. Period.
BOTH ends of any sync device are perfectly capable of determining line
utilization on *any* sync circuit *without* any special protocols.
If you think about this problem for 20 seconds BEFORE running off to design
some bastardization to handle it, you will realize that whenever a sync
channel is idle an HDLC flag is sent down the channel to keep it "alive".
These flags can be *counted* -- easily (Computers are, after all, primarily
counting machines). By counting them, knowing what the wallclock time is
that has elapsed, and knowing the data rate (which is 56 or 64kbps per channel
for ISDN) you can determine TRIVIALLY what the line utilization is within a
few percent.
Now, given this information, which is available to BOTH ends of the
connection for BOTH transmit and receive data, why do you need any kind of
special protocol to bring up and down new channels in an MPP bundle?
Answer: You *do not* need such things.
This is true even if your hardware is too stupid to count BYTES which flow
over the link at the protocol layer -- and most hardware is quite competent
to do that. In fact, most hardware DISPLAYS such data in the connection
status information windows. If you're counting and DISPLAYING it, how o
hard is it to divide by passed time to get BPS rates?
Talk to SGI if you don't believe me. They've done this right now for
something like three+ years, long before MP+ or BACP were even a dream
in the bastard-standards writers eyes.
C'mon ASCEND -- get this one right and quit hiding behind bullshit excuses.
--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
Follow-Ups:
References: