🚀 go-pugleaf

Linda,

Another reason to use frame relay is to minimize serialization delays.
Say for example that you were able to afford only a 56kbps link to
a few different places, and also that your traffic is a mix of character
(telnet/rlogin) and file transfer (ftp, rcp).  The small telnet packets
get stuck behind the large file transfer packets (which are being dribbled
out at 56kbps).  A 1500 byte packet would take 1500*8/56kpbs or 200ms to
serialize out the interface.

Studies have shown that users are willing to tolerate character echo
times of slightly over 200ms if the variance is relatively small.
Now considering that character echos get stuck behind large file xfer
packets somewhat randomly and that when they do they get slowed down
significantly, you can see that not only will the echo times be larger
than the 200ms benchmark, but the variance will also be large.  This
drives users crazy.

Frame relay helps a bit here.  If you can afford a T1 for local loop
(access to the frame relay network from your site), then the serialization
times can be made much less, since the frame relay network should be
running at T1 speeds.  What you have to do then is, given the cost of
private line 56kbps service and the costs of a T1 local loop with whatever
framerelay charges you're likely to incur, make a decision based on
the costs and service levels you can afford.  What you're really doing
is trading off the costs of a T1 over the full length path with the
packet charges of frame relay service to the same destinations (given
that the increase in local loop charges, DS0 to DS1, are affordable
because of increased performance).

This all depends heavily on how much frame relay costs.  So this benefit,
plus the use of a single outbound interface to interconnect multiple routers
(as suggested by Beach) are the major pluses.

Greg Wetzel	+1 708 979 4782	G_F_Wetzel@att.com

AT&T Bell Laboratories (IH 1B-213)
2000 N. Naperville Road
Naperville, IL  60566