TELECOM Digest     Fri, 29 Jul 94 12:07:00 CDT    Volume 14 : Issue 337

Inside This Issue:                           Editor: Patrick A. Townson

    Summary: Bridges vs. Routers (Scott D. Thomas)
    Tie Line Alternatives/Advice Sought (Howard Ball)
    GSM Encryption References Wanted (Niel Viljoen)
    Book Review: "Networking Applications of UNIX Systen V" (Rob Slade)
    Rotary Phones (Wall Street Journal via Daryl Gibson)
    AC 813 Split Press Release (Paul A. Lee)
    Telephony Over the Internet (Willard Dawson)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and GEnie.
It is also gatewayed to Usenet where it appears as the moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * telecom-request@eecs.nwu.edu *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 708-329-0571
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

*************************************************************************
*   TELECOM Digest is partially funded by a grant from the              *
* International Telecommunication Union (ITU) in Geneva, Switzerland    * 
* under the aegis of its Telecom Information Exchange Services (TIES)   * 
* project.  Views expressed herein should not be construed as represent-*
* ing views of the ITU.                                                 *
*************************************************************************

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your help 
is important and appreciated.

All opinions expressed herein are deemed to be those of the author. Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

Date: Thu, 28 Jul 1994 15:48:59 GMT
From: sthomas@mitchell.hac.com (Scott D. Thomas)
Subject: Summary: Bridges vs. Routers
Organization: Hughes Aircraft Company


Hello everyone,

I want to thank everybody who responded to my post about the performance 
differences of bridges vs. routers.  Special thanks to Mike Drollman
of Networks Northwest and Greg Pflaum of Software, Tool & Die.

To summarize: The performance problem with bridges is the unnecessary
broadcast traffic that is forwarded across the WAN.  Bridges CAN do
filtering, some support filtering on specific protocols.  However,
routers enable the network engineer greater flexibility for filtering,
and other technics, such as "spoofing", as suggested by David
Devereaux-Weber.

Thanks again to all those who responded.

        =====================================================

SUMMARY OF RESPONSES TO BRIDGES.VS.ROUTERS POST

 From: Jim Burks <jburks@promus.com>
 Organization: The Promus Companies, Inc.

If you're using the link for LAN-type stuff, you'll find that performace 
suffers, while total utilization on the satellite link is low.

The problem is that LAN activity (file sharing, MS Mail, etc.) sends a
request for a relatively small packet to be returned (~1kb), and waits
for a response before sending the next request.  This is the opposite
of a streaming protocol (such as TCP/IP FTP) that streams data without
waiting for an acknoledgement until a specified window is reached.

Depending on the configuration of the bridges, and software and
network use of them, they can be more efficient on a point-to-point
link, but may pass more broadcast packets between the networks than
necessary.

  From: sdaggett@netrix.com (Steve Daggett)
  Organization: NETRIX Corporation

Actually this is not a "simple network". Depending on the protocol
running on the LAN & WAN segments, the type of data, and the total
usage of each segment of the network things could get pretty strange.

>                         ( ---- )
> host   bridge---sat.---/\      /\ ---sat.---bridge  bridge--DSU
>  |       |     modem                modem      |      |      |
> ------------                                  ----------     |
> *Segment #1*                                 *Segment #2*    |
>                                                           T1 |
>                                                              |
>                                             host   bridge---DSU
>                                              |       |   
>                                            -------------
>                                             *Segment #3*
>

You didn't include the speeds for each of the WAN segments but I'll
assume that the big bottleneck is the satellite hop. You will pick up
about 750 ms delay for every hop over a satellite shot. The delay does
nasty things to protocols like X.25 & TCP that are expecting a
acknowledgment from the far end that the data was transmitted without
error.

You may also have exceeded the capacity of your WAN segments to carry
data. When you exceed the capacity of the WAN your data will begin to
buffer up and increase the delay in the network. You can also
experience a condition called "thrash" were your data buffering up
causes retransmit timers to pop.  The datagrams caught up in the
congestions are retransmitted causing even more congestion in the
network.

There are techniques for setting timers, frame sizes, and window size
to combat the delay and increase throughput on the WAN.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> EDITOR's COMMENT:
>> The following paragraph is incorrect, bridges do filtering, so not all
>> datagrams are passed.

When the entire network was being bridged all datagrams on all
segments were transmitted to every segment in the network. Therefore
heavy usage between workstations on segment #3 could cause network
congestion between segment #1 and #2.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

When you reconfigured to a routed network only those datagrams that
are addressed to a workstation on another segment are actually passed
on the WAN segments. Your traffic is now probably within the capacity
of the WAN segments to carry data and therefore you don't experience
the buffer or network delay.

> I was under the impression that bridges were more efficient because 
> of lower overhead, less complexity, etc.  and therefore would offer
> the better performance.

In some cases bridges offer better performance. Sometimes they are
murder on the network.

If segment #1 was an engineering office running high power
workstations and passing gigabytes of data between stations then a
bridged configuration won't work. If the entire network is an IPX
network with light traffic between users and NOVELL mail servers then
a bridged configuration might work.

As with most things in communications today the official answer is "
well, maybe yes ... maybe no ...".

> Does anyone have thoughts on the matter?

My personal opinion is that bridging in a WAN environment is probally
a bad idea. It's better to go with the routed configuration.

I be out of the office next week so I won't be able to respond to any
follow up posts. I hope this helps to clear things up a little.

  From: leo@elmail.co.uk (E.J.Leoni-Smith)
  Organization: ElectricMail News Service

In general bridge for performance and route for security.

Routing enforces pre-deetermined segmntation. Bridging tends to 
adapt to the traffic. 

Routing also restricts broadcasts, so it tends to keep inter segment
traffic to a minimum 

Bridging is easier to make work at very high throughputs: there is
less computation per packet I think.

 From: cwg@urbino.mcc.com (Chris Garrigues)
 Organization: Microelectronics and Computer Technology Corporation (MCC)

     E.J.Leoni-Smith wrote in article <CtBM89.wM@elmail.co.uk> :
EJLS>
EJLS>In general bridge for performance and route for security.
EJLS>
EJLS>routing enforces pre-deetermined segmntation. Bridging tends to 
EJLS>adapt to the traffic. 
EJLS>
EJLS>
EJLS>Routing also restricts broadcasts, so it tends to keep inter segment
EJLS>traffic to a minimum 

If the network is sufficiently large, on a well engineered network you
can get better performance out of a routed network than a bridged
network because there's better control over what packets are sent
where.  (Give your doom players their own segment.)  The problem is
that a lot of sites don't have the talent available to engineer the
network well, or the physical geography limits the ability to properly
segment traffic.

 From: David Devereaux-Weber <weberdd@clover.macc.wisc.edu>
 Organization: TELECOM Digest
                                                                      
It depends on what protocols the network is carying.  Routers can
improve performance on several protocols by reducing unnecessary
broadcast traffic -- for example, in an IPX network, if there are many
servers, the servers periodically advertise their resources to the
network in broadcast messages.  Routers can suppress redundant
messages like that and then regenerate them on the other end of a
link.  Furthermore, plain old IPX (without packet burst) sends a
packet at a time and then waits for an acknowledgement that the packet
arrived at the far end.  A satellite circuit has a significant delay,
which severely limits throughput.  Routers can "spoof" the IPX
protocol by sending an acknowledgement (an electronic white lie) from
the local router before the packet is recieved by the far end.  The
far router blocks the acknowledgement, because it knows the near
router has already simulated it.  Because of the magnitude of the
delay of the satellite link, several packets can be in the pipeline
during the time required to send just one and wait for the ack.

If your network is IP, much of the broadcast traffic (like ARP
packets) can be kept off narrow bandwidth long delay circuits like the
satellite link.

So, in a purely local, wide bandwidth network, a bridge has less
latency than a router, but in a narrow, long delay network like one
with a satellite link, a router can reduce broadcast traffic and
improve performance on many protocols.


 From: lars@Eskimo.CPH.RNS.COM (Lars Poulsen)
 Organization: Rockwell Network Systems, Copenhagen DENMARK

> I have a puzzling (at least to me) situation.  We have a simple
> network with a satellite link included.  Orginally, we bridged three
> ethernet segments ...  ... ... ... ... ... and got poorer that expected
> results.  We decided to replace the bridges with routers, one per
> segment.  The throughput was tripled!

> I was under the impression that bridges were more efficient because of
> lower overhead, less complexity, etc.  and therefore would offer the
> better performance.

The most likely reason for your poor performance, is that one of the
sites in question is a LARGE network (maybe several hundred stations
or more ?) and the amount of broadcast/multicast traffic floating
around in the network is eating up all the bandwidth of the DS-1 link.

When connecting multiple LANs into one extended network, the
connection can be implemented with different logical models.

Bridging is the lowest level model; it takes to similar networks (such
as two Ethernets or two Token-Rings) and joins them intpo one logical
network. A bridge device on each end of the link:

- goes into promiscuous mode (snooping on all traffic)
- keeps track of which devices (identified by their Ethernet addresses)
  are on each end, and
- forwards traffic for any device not know to be on the same LAN as
  the sender, as well as all broadcast/multicast messages across the link.

Because this is done at Media Attachment Control (MAC) level, it is
protocol independent, and requires very little setup.

The downside is that all broadcast/multicast traffic is forwarded, as
well as traffic from protocols that are entirely unsuited for wide
area traffic. The larger the combined network, the larger the amount
of background "slosh" og broadcasts, even as a percentage of total
traffic. (For instance, every ARP request will be sent everywhere,
theough almost all of them are for stations local to the sender.)
When you have a couple hundred workstations, you are likely to have
about 32 Kbps worth of "slosh". (Meaning you need a T1 to get any WORK
done.)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> EDITOR's COMMENT
>> Some bridges can and do filter on protocol type, and can filter all
>> broadcasts.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

To overcome the deficiencies of bridging, you need a router. Routers
must understand each protocol and must be configured appropriately for
each protocol. This means that somewhere in the organization there has
to be a person who understands each protocol that is being routed, and
who can set up an addressing plan and troubleshoot when problems
arise.

For a good textbook in this area, I recommend Radia Perlman's book
"Interconnections: Bridges and Routers". Addison-Wesley, 1992.  ISBN
0-201-56332-0. I think I paid $53.26 (incl CA tax).

                       ------------

Scott Thomas                       
Hughes Information Technology Corp.
e-mail: sthomas@mitchell.hitc.com  
 phone: (703) 759-1382             
   fax: (703) 438-8430             

------------------------------

Subject: Tie Line Alternatives/Advice Sought
From: howard.ball@execnet.com (Howard Ball)
Date: Thu, 28 Jul 94 22:21:00 -0500
Organization: The Executive Network Information System


Does anyone know of a cost effective microwave or radio link for
tie-lines:

My employer (a specialty retailer) relocated my department
(communications) in a building next to the building of several other
departments. This is in midtown Manhattan. The buildings do not have
any common passageway, having their own walls, however there is a
courtyard common between them.  We lease our space in these buildings
which house other lessees as well.

Each of our office locations has its own PBX. We guess that there are
about 100 calls made between buildings. (I will research traffic as
part of the process of implementing a tie; however, the decision to
link was made by senior management and a cost limit given. This is not
really an investment decision. While least (475 min left), (H)elp,
More? nscost is still desirable, least cost would be to continue with
no change.) I would like between 4 and 24 channels, depending on cost
and traffic.

Presently calls from one location go out to the central office just
like any other Manhattan call.  My manager has decided not to use tie
line arrangements via NYNEX on the basis of cost. I am exploring
having a cable routed along the courtyard which will mean drilling
holes through the walls.  Only one of our premises has windows facing
this courtyard.

We will need the permission of the building management to implement
the external cabling.  I would like to scope out other alternatives
such as microwave or radio link.  While 900 Mhz cordless phones would
probably span the gap, this would not be a tie-line arrangement which
is desired so that anyone in one building could call anyone in the
other building with a 4 digit extension the same way they make
internal calls now and also share our lower cost long distance
service.

A multichannel radio link that could be connected to telephone pairs
in the same way trunks would be acceptable. Similarly if microwave
located INSIDE could span the 30 foot gap and penetrate the wall and
window, fine.

I also had the thought of bouncing signals off buildings across the
street; both locations have windows facing this major wide avenue. In
these cases, the link must be reliable in all kinds of weather. We
would not be able to make any arrangements with the building owners of
these facing buildings for either reflectors or notification of
construction, demolition, etc.

Can anyone recommend equipment vendors with possible solutions?


Thanks,

Howard   Reply via Internet to howard.ball@execnet.com

------------------------------

From: niel@marge.mikom.csir.co.za (Niel Viljoen)
Subject: GSM Encryption References Wanted
Date: 29 Jul 1994 19:49:07 GMT
Organization: Mikomtek - CSIR


1) Could anybody point me to some references as to the algortihms (if public).
2) Are these always used?


Cheers and thanks,

Neil

------------------------------

Date: Thu, 28 Jul 1994 13:09:22 MDT
From: Book Review: Rob Slade <roberts@decus.ca>
Subject: Book Review: "Networking Applications of UNIX Systen V" by Padovano


BKNTAPUN.RVW  940504
 
Prentice Hall
113 Sylvan Avenue
Englewood Cliffs, NJ   07632
(515) 284-6751
FAX (515) 284-2607
or
11711 N. College Ave.
Carmel, IN   46032-9903
or
201 W. 103rd Street
Indianapolis, IN   46290
or
15 Columbus Circle
New York, NY   10023
800-428-5331
or
Market Cross House
Cooper Street
Chichester, West Sussex PO19 1EB
England
phyllis@prenhall.com - Phyllis Eve Bregman is postmaster
70621.2737@CompuServe.COM Alan Apt
Beth Mullen-Hespe beth_hespe@prenhall.com
"Networking Applications of UNIX System V", Padovano, 1993, 0-13-613555-2
padovano@remus.rutgers.edu
 
As the title implies, this text is primarily of use to those studying
the System V Release 4 variant of UNIX (descended from the AT&T
family), which also covers implementations such as Solaris 2.  The
STREAMS model is introduced, and while TCP/IP, UUCP and NFS are
covered, it is from an SVR4 perspective.
 
Within these limits, the book is clear, well organized, and complete.
Each chapter contains a well-chosen bibliography, and a challenging
set of exercises.
 
The text concentrates on functions rather than applications.  This is
a departure from a number of recent texts which present the concepts
within a framework of a larger program, but the code presented is
ample to illustrate the points being made.


copyright Robert M. Slade, 1994   BKNTAPUN.RVW  940504. Distribution 
permitted in TELECOM Digest and associated newsgroups/mailing lists.


Vancouver      ROBERTS@decus.ca    
Institute for  Robert_Slade@sfu.ca 
Research into  rslade@cue.bc.ca    
User           p1@CyberStore.ca    
Security       Canada V7K 2G6      

------------------------------

Date: Thu, 28 Jul 1994 14:36:51 MST
From: Daryl Gibson <DRG@du1.byu.edu>
Subject: Rotary Phones


The July 28 {Wall Street Journal} has a piece on the trials of using a
rotary phone. Obviously, copyright law and all, I can't quote the
whole thing, but I thought you'd find these two paragraphs
interesting ...

        A major point of rotary's appeal is their
    durability. Cased in metal or bakelite, a
    very durable plastic, a rotary phone can stand
    up to a lot of torture. When he was 12 years old,
    Russell Carrick of Boston remembers watching his
    friends trying to blow up rotary phones by placing
    firecrackers beneath them.

        "It did nothing," recalls Mr. Carrick, now 25. 
    "Those phones were built like tanks."
    
The story also notes that AT&T *leased* about 20,000 refurbished
rotaries last year, and continues to offer the phones because there is
still a demand.

It also features the following:
        
        Some people are simply nostalgic. "These phones
     lived through the Depression, World War II, Prohibition,"
     says Mike Margolius, an Atlanta antiques dealer who specializes
     in restoring rotaries. "If these phones could talk, it's
     great what they would whisper in your ear."
     

Daryl
      (801)378- 2950        (801) 489-6348
      drg@du1.byu.edu       71171.2036@compuserve.com


[TELECOM Digest Editor's Note: Well Daryl, those phones go back to the
time now over a decade ago when the Bell System used to run the phone
network in the USA. In those days, a lot more people too pride in their
craftsmanship. Phones quite often lasted 40-50 years without breaking
down. Now and then you still see one of those better quality older phones
around, still in service. I think the same article in the WSJ said that
about 11 percent of the people in the USA still prefer to use rotary dial
service. When I have occassion to use it I find it a nuisance.   PAT]

------------------------------

Date: Wed, 27 Jul 1994 12:34:23 -0400
Subject:  AC 813 Split Press Release
From: Paul A. Lee  </DD.ID=JES2CAOF.UEDCM09/@SMX.sprint.com>
Organization: Woolworth Corporation


Since we have sites in GTE Florida territory, a recent mention in
{TELECOM Digest} of an impending split of NPA 813 caught my attention.
I contacted GTE Florida and they sent me the following press release:


June 30, 1994

          GTE Customers in Polk, Manatee and Sarasota Counties
                 to Receive New 941 Area Code in 1995

Tampa, FL -- The 813 area code will be divided into two area codes
effective May 28, 1995. GTE customers in Hillsborough, Pinellas and
Pasco counties who currently have an 813 area code will keep the same
area code. Customers in Polk, Manatee and Sarasota counties will be
assigned the new 941 area code.  Sprint/United Telephone-Florida
customers in the 813 area will also be assigned the new 941 area code.

The new area code is necessary because the southwest coast of Florida
is running out of seven-digit telephone numbers. According to GTE
Florida President Peter A. Daks, the demand for telephone numbers has
increased due to population growth, business expansion, and new
technologies. "Customer use of cellular phones, fax machines, pagers,
computer modems and other technologies has exploded," said Daks.
"Without this split, we projected that we would literally run out of
telephone numbers in late 1996."

Between May 28, 1995 and March 3, 1996, callers are encouraged to
begin using the new 941 area code. After March 3, 1996, it will be
mandatory to dial the new area code or callers will receive an
intercept message instructing them to redial using the 941 area code.

The area code boundaries were designed to allow maximum time before
the next area code split would be necessary. GTE's current forecasts
indicate the 813 and 941 area codes will provide sufficient telephone
numbers to accommodate growth until 2012.

GTE Florida, Inc. provides high-quality voice and data communications
services to customers through approximately two million access lines
in Hillsborough, Manatee, Pasco, Pinellas, Polk and Sarasota counties.
 
                       ---------------

Paul A. Lee                           Voice  414 357-1409
Telecommunications Analyst              FAX  414 357-1450
Woolworth Corporation            CompuServe  70353,566
   INTERNET  </DD.ID=JES2CAOF.UEDCM09/@SMX.sprint.com>  

------------------------------

From: wdawson@willard.atl.ga.us (Willard Dawson)
Subject: Telephony Over the Internet
Organization: Willard's House
Date: Fri, 29 Jul 1994 11:08:19 GMT


A discussion currently conducted on the com-priv mailing list has
mentioned that there already exists software to allow one to do
two-way voice conferences (aka, a telephone call) over the Internet.
Is there a convenient summary of the state of the art, hopefully
including a list of available software?

One of the posters on com-priv mentioned a program called IVC.  My
inital archie searches turned up nothing ...

------------------------------

End of TELECOM Digest V14 #337
******************************
