Re: Smoking gun in CA

[rberger@Internex.NET (Robert Berger)]

  > In
  > 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
  
  01/08/96
  
       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
  the de-
  vices at the either end of the call are made by different vendors.
       Static guard
       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
  standard.
       Even within the association, different sites use different equipment,
  he said.
       '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