🚀 go-pugleaf

I have some insight here, as we have been benchmarking several models
of ISDN equipment for the past few weeks.  Of the four units we are looking
at (Bay Remote Annex 6300, Ascend Max400x and TNT, USR Total Control Hub,
and Cisco (if it ever gets here) 5210), only the Cisco claims to "bond 
across boxes".  Ascend claims to know about the problem, but chooses not 
to ship their boxes with this feature as they claim it impacts performance.
My fuzzy understanding of how it is accomplished involves all the term 
servers on a segment broadcasting a proprietary protocol that informs the 
others when the first B channel of an MPPP connection is accepted.  When 
the second B channel is accepted, the server that accepted it *should* 
know which server has the first channel, and proceeds to "forward" the 
packet pieces to the first term server (over what protocol I am not 
sure... perhaps just tunneled in IP?) for re-assembly.  I would accept 
that there may be some latency in this process.  Don't forget traffic in 
the other direction.  The server with the first channel will get the 
traffic that is bound for the user, and will have to make some decision 
to split it up and send pieces to the server with the second channel.

Ascend sales claims that this process impacts performance by 25% .

As a service provider, we are stuck with a greuling problem.  We can let 
the customer call and bond every time with a likely 25% performance cut, 
or we can make them redial until they get both on the same box, which in 
a large situation could be very rare (probably Alternet's situation).

There are a couple solutions as I see it:

1.  Buy a bigger box.  Two of the vendors mentioned above claim that an OC3
capable server will be available next year.  Thats somewhere in the 700 B 
channel range, folks.  Might as well become your own local CO :)  This 
solution is a good one, if the hardware is actually up to it.  It 
probably scales *fairly* well, until the time (if it comes) that ISP's 
will have to handle 25,000 simultaneous calls.  Even then, distributing 
customers across a few tens of these monsters probably wouldn't be 
extremely difficult.

2.  Dedicate customers to servers.  This was mentioned in your post as 
something that Alternet decided NOT to do.  I can see why, as well.  This 
does not scale at all.  People sign up, people quit.  It would be a 
nightmare to manage a few hundred lines in this manner, and I am guessing 
that Alternet on a global scale has more than a few hundred lines :) .
Nonetheless, it is the best we can do until more options are available, IMHO,
and is what we are planning to do.

Has anyone come up with any other solutions?

Jeff LaCoursiere
FastLane Communications, Inc.

On Mon, 16 Sep 1996, David Thielen wrote:

> Hi;
> 
> Here's the scoop. When we moved I switched to UUNET figuring that they
> had a better system than anyone else out there. When I signed on I was
> told that I could only get 128K access if, when I connected, both
> lines hit the same router (apparently they were waiting for a software
> update from Ascend). I was also told that within 2 months this would
> be fixed.
> 
> Well, trying several times including a week straight where I tried at
> 2:00 - 3:00 AM - no luck on getting a 128K connection. And over 2
> months passed and I was told that the router upgrade is still in the
> indefinite future.
> 
> Now this is where it gets interesting -- because things can take
> longer than sales people promise.
> 
> I have a permanent connection. Now, it would make sense to assign 1
> router 1 set of call lines for a group with a permanent connection.
> Then each person in that group would get a 128K connection and nothing
> would be unused.
> 
> This was discussed at UUNET and they decided to not do it. Why? No one
> knows.
> 
> The second suggestion was to assign each router its own set of phone
> lines so you never have 1 line connect to 1 router and the second to
> another. Again, this was discussed at UUNET and they decided to not do
> it.
> 
> My third request was for them to tell me if dialing in would/should
> give me a 128K connection at that time. While they have this
> capability, they will not do this. Why? No reason given.
> 
> Here is what I think is happening. If they allow ISDN customers to
> connect at 128K, then they need twice the number of ISDN phone lines,
> twice the number of routers, and twice the bandwidth from those
> routers.
> 
> So, by effectively limiting all ISDN users to 56K they cut their costs
> in half while still providing ISDN.
> 
> And with quick talking sales people, no one realizes they are only
> getting half a line from UUNET.
> 
> So, if you want full ISDN -- don't use UUNET. (And if you are in the
> D/FW area, call unicomp -- I got a FULL ISDN link from them with no
> problems.)
> 
> - dave
> 
>