Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!oberon!castor.usc.edu!blarson
From: blarson@castor.usc.edu (Bob Larson)
Newsgroups: comp.dcom.lans
Subject: Re: OSI-model software
Message-ID: <2886@oberon.USC.EDU>
Date: Sat, 20-Jun-87 07:31:46 EDT
Article-I.D.: oberon.2886
Posted: Sat Jun 20 07:31:46 1987
Date-Received: Mon, 22-Jun-87 05:15:57 EDT
References: <1204@botter.cs.vu.nl> <1680@munnari.oz> <192@ditmela.OZ> <943@bloom-beacon.MIT.EDU> <1707@munnari.oz>
Sender: nobody@oberon.USC.EDU
Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 45
Keywords: osi, iso, internetworking

In article <1707@munnari.oz> kre@munnari.oz (Robert Elz) writes:
 >In article <943@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo)
 >writes:
 >> ... X.25 level 3 has a flow control window.  Anyone who
 >> has tried to run kermit over a PSPDN knows how well all the
 >> transmission windows interact.
 >
 >Huh?  I always thought that the problem with kermit over
 >x.25 nets is precisely because kermit doesn't have a windowing
 >flow control scheme (or it has the terminal case, of a window
 >size of 1).
 >
 >That is, kermit sends a packet, then waits for an ack.
 >
 >Packet turnaround in x.25 networks is typically fairly slow,
 >but this is neither a problem with x.25, nor with the windowing
 >scheme (which is effectively a no-op when protocols like
 >traditional kermit are used above it).  Rather, its a problem
 >with the comparatively low capacity technology used to implement
 >the networks.

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.  (kermit packets are shorter
than x.25 packets.)  This is an implementation rather than pure standarization
issue, but standards which allow rediculous behavior (waiting for output
from a process that is waiting for input) somewhat deserve the critisism
they get.

 >I doubt I'm alone in this belief, as I gather that the kermit
 >people are defining a new protocol (extended protocol) with
 >windowing in it, precisely so it will work *better* over x.25
 >type networks.

Full duplex windows has been an accepted option to the kermit protocol
since the 6th edition of the protocol manual.  (Published about a year
ago.)  I just wish they were part of c-kermit, the unix kermit
implementation.  (Prime kermit and Procom for the Ibm Pc are two examples
of kermit implementations that do support full duplex windows.)

Full duplex windows are a win in any situation where the communications
speed is limiting the speed of the file transfer.  They just win
bigest when the communications delays are long.
Bob Larson		Arpa: Blarson@Ecla.Usc.Edu
Uucp: {sdcrdcf,seismo!cit-vax}!oberon!castor!blarson
"How well do we use our freedom to choose the illusions we create?" -- Timbuk3