[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Smoking gun in CA
> california, PacBell has about 15 million lines, of which about 5,000 are
> under the residential ISDN tariff, and of those, apparently about 75
> percent are used less than 40 hours per month...(This info via the
> grapevine, I haven't seen any documents). So it's hard to understand
> where all the congestion is comming from in California, or if this is a
> smokescreen for something else..
The problem you face when you offer flat rate for a limited resource you end up
with the "destruction of the commons" effect. The path of least resisstance for
Internet access is to be connected all the time. If there is no disincentive to
not nail up the line, then a large portion of the population will nail up the
line. Not everyone has to do this to tie up the scarce resources of inter
office trunk lines.
So Pac Bell isn't wrong in being concerned, even if its not a problem today, it
would become a problem very quickly. Were they are wrong is how they implement
the disincentives as well as not promoting technological and economic
mechanisms to offer a service that is almost like a permanent connection in
ways that are
appropirate for the dialup customer as I noted in an earlier note.
Someone pointed out in a private email, that its highly unlikely to expect
the phone companies to be in the lead to push the technical solutions. Instead
we should promote this concept to the equipment manufactures. The best forum
for this is the BACP:
ISDN kingpins push for standard protocol
By Tim Greene
By Tim Greene
Seven industry heavyweights are coming to the rescue of users that
want ISDN lines to accommodate changing bandwidth needs, a capability
rendered difficult today due to the proprietary protocols vendors employ.
The answer, according to Ascend Communications, Inc., Bay Networks,
Inc. (including its Xylogics division), Cisco Systems, Inc., Microsoft
Corp., Shiva Corp., 3Com Corp. and U.S. Robotics, is the Bandwidth
Allocation Control Protocol (BACP).
BACP would remove a major stumbling block to ISDN use: the ability
during a call to add and subtract bandwidth in 64K bit/sec chunks, even if
vices at the either end of the call are made by different vendors.
Today, incompatible equipment usually cannot exchange the information
needed to scale links up or down, so the bandwidth remains static,
according to Bob Larribeau, director of the California ISDN Users Group.
If devices at either end of a line used a standard protocol, they
could add and drop channels as needed (see graphic).
For example, telecommuters using a single 64K bit/sec Basic Rate
Interface line could jump up to 128K bit/sec by bonding in
a second B channel for large file transfers.
Corporate users of a Primary Rate Interface could bump up bandwidth to
384K bit/sec for a videoconference.
Reaching an agreement
Ascend had been pushing its own protocol, called MP+, for the industry
standard but backed off to support BACP, which was written by Shiva and
modified with collaboration from the other companies.
Bernie Schneider, vice president of marketing for Ascend, said it was
more important to get industry agreement on one standard, rather than cling
to the protocol it authored.
'We know that standards are an absolute must for the [ISDN] industry
to grow and flourish, particularly with Internet growth,' he said.
Schneider added that the company would continue to use MP+ in its
equipment but it would add BACP if the protocol becomes a standard.
Rich Eastman, vice president of engineering and network design for
Virtual Presence International, which uses ISDN for videoconferencing among
members of the World Trade Centers Association, likes the idea of a
Even within the association, different sites use different equipment,
'To have a dynamic increase and decrease of bandwidth now, we have to
have the same manufacturer's equipment at each end,' Eastman said.
When the equipment is from different vendors, he has to manually dial
up additional channels to get enough bandwidth for a videoconference.
If there was a standard, that additional bandwidth would be set up by
the equipment itself.
BACP has been presented to the Internet Engineering Task Force (IETF)
because BACP builds on the PPP and Multilink Protocols, which fall under
the IETFs purview.
While some BACP backers will wait to see if the technology is accepted
as a standard before building it into a product, Microsoft plans to support
BACP in Windows NT later this year.
Copyright 1995 Network World, Inc.
Robert J. Berger - CTO / VP of Engineering
InterNex Information Services, Inc. 2302 Walsh Rd. Santa Clara, CA 95051
Voice: 408-327-2290 Fax: 408-496-5484