Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ihlpl!jhh
From: jhh@ihlpl.UUCP
Newsgroups: comp.dcom.lans
Subject: Re: OSI-model software
Message-ID: <2289@ihlpl.ATT.COM>
Date: Tue, 23-Jun-87 17:55:53 EDT
Article-I.D.: ihlpl.2289
Posted: Tue Jun 23 17:55:53 1987
Date-Received: Fri, 26-Jun-87 02:02:04 EDT
References: <1204@botter.cs.vu.nl> <1680@munnari.oz> <192@ditmela.OZ> <2886@oberon.USC.EDU>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 31
Keywords: osi, iso, internetworking
Summary: X.25 does not have any delay before transmit timers

In article <2886@oberon.USC.EDU>, blarson@castor.usc.edu (Bob Larson) writes:
>  >traditional kermit are used above it).  Rather, its a problem
>  >with the comparatively low capacity technology used to implement
>  >the networks.
It's not really the capacity that is the problem, rather it is
the X.25 network delay that causes delay perceived by the user.
Admittedly, delay is usually related to capacity just because
higher capacity implementations have that much less time to
process and delay a packet.  The number of network nodes that
a packet traverses, along with the trunk speed connecting the
nodes has a much greater impact on delay.  If an X.25 network
requires the full packet to be received before it processes it
and sends it to the next node, there is an insertion delay
(number of bits in packet divided by the line speed).  For
example, 60 milliseconds are required to receive a 64 byte message
at 9600 bps.  With a protocol that has a window of 1,
the transmiter must remain idle for at least the number of
intermediate nodes times 60 milliseconds (assuming 9600 bps
internal trunk speeds).  At higher trunk speeds (56Kbps for example),
the internal node processing time becomes a more significant factor.

> Some implementations of x.25 do not realize that no further data will be sent,
> so have to time out before the packet is sent.
This has nothing to do with X.25, but rather the device that is
converting the asynchronous data into X.25.  This is typically
a function on an X.3/X.28/X.29 PAD (Packet Assembler/Disassembler).
In particular, two X.3 parameters that affect when an asynchronous
stream should be forwarded are 3 (selection of data forwarding
characters) and 4 (selection of idle timer delay).

John Haller