TOPIC ---------------------------------------------
I am working toward extending our AppleTalk network from Plano, Texas, to
various other offices (such as, specifically, Anchorage via 56Kb phone links
for Ethernet). This 'extended' Ethernet is primarily being done to support
some VAX systems, but AppleTalk packets get out over the TransLan bridges
anyway, so AppleTalk goes 'piggyback' on the Ethernet with no particular
trouble.
So far, Plano and downtown Dallas are connected. There is Liaison and
FastPaths on the Plano end and Liaison in Dallas. AppleShare servers and
printers and zones show up fine, although response time is a bit slow.
In a few weeks, I hope to have Anchorage on-line via telephone satellite. I
have been trying to get some idea of how bad the delay caused by the satellite
phone link will be.
Are any software packages that make use of the ADSP protocol (which sounds to
me like what we really need for eliminating the wait for every packet's
response)?. For instance, I've heard that CE's newest QuickMail product does
this. Based on the times involved, my estimate is that the time delay due to
the 24,000 mile distance to the satellite will be slightly better than that
seen with a Liaison remote phone link with a 9600-baud modem.
Is this reasonable, or is there some other problem I don't know about? Will
AppleShare tolerate these time delays?
DISCUSSION ---------------------------------------------
A satellite link will add approximately a quarter-second delay between the time
a packet is transmitted at one end of the link until the time it is received at
the other end of the link. This propagation delay is about 15 times greater
than that seen in a 3000-mile ground link, which approaches a fiftieth of a
second. This assumes perfectly clean channels; when you include error rates,
ground-based analog lines have greater error rates than satellites, which
require more retransmissions.
The quarter-second delay would be most noticeable in the case of extremely
bursty types of communications. The best example of this type of communication
is a full-duplex character mode terminal session. If the character typed at
the terminal has to be echoed by the remote host before it is displayed on the
screen, you see a one-half-second delay between the time a character was typed
and the time it was displayed on the screen.
At the other end of the spectrum is the completely one-way transmission of
large amounts of data. The quarter-second delay caused by the satellite link
would then become virtually unnoticeable.
Reality will fall somewhere between these two scenarios. Typically, the
amount of data transmitted in each AppleTalk packet will be in the hundreds
of bytes. Also, constant send/receive-style communication is greatly
reduced. For instance, communication between a Macintosh and a LaserWriter
follows the pattern of 8 data packets being sent by the Macintosh, followed
by a request for the next set of 8 sent back by the LaserWriter. This
transaction-based communications is at the heart of most AppleTalk traffic.
AppleShare servers and LaserWriters communicate via the AppleTalk
Transaction Protocol (ATP), which implements these communications along
with guaranteed packet delivery. Using files servers and printers over
this long distance link, as if they were locally attached, is not a
recommended solution. However, we have seen these types of operations work
reliably at speeds as low as 1200 baud via asynchronous links, so
communications via the satellite link should work.
Problems that slower speed links cause often are caused by errors on the
network. Satellite links themselves are very reliable, but if one of the ends
of the link is having network errors, continual retransmission requests across
the link, due to packets lost on the misbehaving side, will cause problems.
This makes it doubly important that the quality of the networks on both sides
be doubly checked and well within the recommended limits of cable lengths and
nodes per network.
Also, in AppleTalk Phase 1, there is no best router algorithms in use, so
sometimes a Macintosh will use a router on the other side of a slow link as its
router to devices on its side of the link. This is a problem only with
Macintoshes directly connected (via Ethernet cards, and so on) to the backbone
that includes the long distance link, and it can cause significant delays.
AppleTalk Phase 2 addresses this problem, and your customer should seriously
consider upgrading to Phase 2.
To address the ADSP question above, ADSP is typically used for data-stream-type
communications over a network. The classic example of this is terminal
services over a network. ADSP was implemented to try to reduce the impact of
the problems posed by the character-by-character nature of these transactions.
We do not see a need to look for other network applications that specifically
use ADSP unless you are looking at the possibility of terminal services across
the remote link, such as logging on to a VAX via PacerLink.
It is important to realize that the actual throughput and user-perceived
throughput will vary on a case-by-case basis. As the backbone traffic
increases, causing more delays due to nodes waiting to send, the actual delay
from the satellite link will become a smaller and smaller portion of the
overall delays on the network. If network services are configured to take the
link into account, perceived throughput will be even greater. For instance,
electronic mail services could be configured so that messages sent across the
link were only sent twice a day at low-activity periods.
As a final note, the issues discussed above are mostly not AppleTalk- specific.
Adding satellite links to any networking schemes magnifies the complexity of
that network by an order of magnitude. This is definitely not a plug-and-play
operation (not yet, anyway), but it has been successfully implemented within
the AppleTalk world, and much more often in the TCP/IP world.