Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Mar 1996 22:18:38 -0500 (EST)
From:      Chuck Robey <chuckr@Glue.umd.edu>
To:        Terry Lambert <terry@lambert.org>
Cc:        terry@lambert.org, hasty@rah.star-gate.com, chat@freebsd.org
Subject:   Re: Act Now !
Message-ID:  <Pine.OSF.3.91.960307221046.30386A-100000@gilligan.eng.umd.edu>
In-Reply-To: <199603080059.RAA15305@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 1996, Terry Lambert wrote:

> > Actually, several years ago, when it was still a telecommunications 
> > company, ITT tried real hard to make a voice switch based upon a packet 
> > switching core.  It was an incredible failure, and took ITT's reputation 
> > down into the toilet with it.

I am a little puzzled.  I saw your notice on hackers, moving this to chat 
(quite correctly) saying that Chuck is wrong, and message unit based 
charging must die.  I think I have that correctly, anyway.  I'm confused, 
because I was never arguing that message based charging was anything at 
all, I was arguing that the internet can't absorb even a tiny, tiny 
fraction of the voice traffic (that nows runs on dedicated voice 
networks).  I don't see where the topic changed, but if it has, to that 
topic, I'm not holding any position there at all, and I don't want to 
argue it.  Maybe I should let this drop here.

I was started because of that Voice Over Net article that was posted, 
and the (un)reasoning over the telco's response to what I saw as a 
non-issue.  Since it couldn't possibly happen, why would they make a fuss 
over stopping the impossible (today's impossible being, of course, 
tomorrow's obvious path).  It's impossible today, why worry it?  When it 
becomes possible, it's going to happen anyways, because of all the 
unregulation.

> 
> They tried to do this before the data technology was really there.
> 
> The Northern Telecom DV series of switches uses a message passing
> backplane, and does this type of thing regularly.
> 
> ATM is based on the avility to packet-switch both voice and video
> (though "leaky bucket" -- uncommitted data rates -- sucks for using
> ATM for data, but that's an ATM problem).
> 
> The point is, packet-switching technology exists and is being deployed
> frequently.  Check out the products for buildings and Campuses from
> Sumitomo Electric (they did the blown fiber installation in every
> building on the University of Utah campus) or the Salt Lake City
> company Electric Lightwave, which runs a fiber to your site when you
> sign up and offers combined phone and data services over a packet
> switched network.
> 
> > Circuit switching, when you have a steady data load (like voice has) is 
> > far, far cheaper than any technology that tries to adjust itself to user 
> > demand.  Cheaper in terms of hardware for the telephone companies, and 
> > that's why it costs more for ISDN or Frame Relay that your regular home 
> > phone.  Maybe this is changing, maybe even right now, but it's true at 
> > this particular point in time.
> 
> The switches are cheaper, if you assume a certain amount of bandwidth
> overcommit (which is unacceptable for data, which requires committed
> rates), and you *don't* include the ADAC's and line drivers to get
> to the analog lines, which are what is actually going out to your
> house.
> 
> The reason it costs more for Frame Relay and ISDN is that the RBOC's
> have to actually upgrade their equipment to 5ESS or better switching
> to be able to run the software, and they don't like not being able
> to amortize the existing hardware over a 20 year period.
> 
> I say "tough beans".  It's that narrow mentality they have that
> resulted in the installation of a "brand new" *mechanical* switch
> in a small town in Southern Utah by US West, who was trying to
> stretch the amortization on the thing another couple of years.
> 
> > Actually, like I said originally, if only 10 percent of _just hackers_ 
> > began making all their calls via the internet, the internet would bow 
> > under the traffic strain.
> 
> Fine.  Bring it on.  The backbone NSP's need to upgrade anyway.  They
> should be running 10Gbit of each and every one of the Sprint
> transcontinental Fiber lines anyway, IMO.
> 
> > On top of this, the technology that Amancio 
> > and company is using will not support high speed modems.  Nearly all 
> > existing long distance networks will support high speed modems (I know 
> > this because I was tasked to test this assertion several years ago).
> 
> Who the hell needs to run a 28.8 modem to turn the digital into analog
> to digital to analog to digital again, when you have a 56k line in place?
> 
> The voice compression crap is *supposed* to be lossy to allow marginal
> bandwidth overcommit.  Other than AT&T and TelAmerica, I was having
> problems with LD carriers and space compression when trying to use
> the early high speed Telebit and US Robotics modems back in 1987.
> If you don't like it, vote with your $ for carriers who don't pull
> that kind of crap to get out from under the fact that the AT&T
> breakup decree was about to expire and AT&T no longer had to provide
> them with free use of ther transcontinental microwave network (THAT'S
> what drove Sprint to lay the fiber pipes in the first place...).
> 
> > I can't completely understand why, in the face of this fairly obvious 
> > fact, why the big phone companies are reacting.  I suspect they're 
> > concerned somewhat with appearances, showing they're not the only show in 
> > town, which they certainly aren't anymore.
> 
> Data pipes are about to become a commodity item, thanks to the cable
> companies.  It's the same argument that was used for proprietary
> Mac hardware: only Apple has (apparently, and only recently) learned
> that it's better to have 30% of 100% than 100% of 8%.
> 
> The cost curve on phone service has long been biased for local calls,
> with long distance subsidizing the majority of the infrastructure.
> Why do you think AT&T kept their data processing and long distance
> services and spun off the RBOC's, instead of the other way around?
> 
> Once you start only paying to get in, with no regard to the
> destination, the LD companies have to start charging a flat rate
> based on pipe size, and their profits go down the toilet.  The
> RBOC's have to then pay based on pipe size to the interconnect,
> and then there's no such thing as "long distance" because of
> the impossibility of keeping accurate accounting records for
> so much packet traffic that per-packet accounting is impossible.
> 
> That's incidently why ATM connections aren't more popular: the
> accounting problems are too large to use traditional mechanisms;
> the LD companies will use it internally and front the actual ATM
> with circuit switched access to VC's so they can still generate
> per-call acounting records.
> 
> The ability to do that goes out the window when you can no longer
> monitor the buildup and teardown times for the VC's for a given
> "call".
> 
> 
> I think this "Act Now!" bulletin is silly; the change over is
> economically inevitable, and I have no compunctions against
> attending the funeral of the dinosaurs who refuse to "get with
> the program".  The only thing their petition can result in is
> a delay in "When", not a change in "If".  The course of events
> is inevitable.
> 
> 
> 					My opinions,
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 

==========================================================================
Chuck Robey chuckr@eng.umd.edu, I run FreeBSD-current on n3lxx + Journey2
 
Three Accounts for the Super-users in the sky,
  Seven for the Operators in their halls of fame,
Nine for Ordinary Users doomed to crie,
  One for the Illegal Cracker with his evil game
In the Domains of Internet where the data lie.
  One Account to rule them all, One Account to watch them,
  One Account to make them all and in the network bind them.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.91.960307221046.30386A-100000>