Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!munnari!kre
From: kre@munnari.UUCP
Newsgroups: comp.protocols.iso,comp.dcom.lans
Subject: Re: OSI-model software
Message-ID: <1711@munnari.oz>
Date: Sat, 20-Jun-87 13:45:50 EDT
Article-I.D.: munnari.1711
Posted: Sat Jun 20 13:45:50 1987
Date-Received: Sun, 21-Jun-87 06:56:39 EDT
References: <1204@botter.cs.vu.nl> <1680@munnari.oz> <192@ditmela.OZ> <2886@oberon.USC.EDU>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 25
Keywords: osi, iso, internetworking
Xref: utgpu junk:5303 comp.dcom.lans:508

In article <2886@oberon.USC.EDU>, blarson@castor.usc.edu (Bob Larson) writes:
> 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.

Any X.25 implementation that does that is 100% bogus, and I actually
doubt that there are any such implementations.

However, X.28 does have this "feature".  (This is what you get when
you connect to X.25 via a PAD).  However, it can be controlled in
various ways, most of which, due to completely hopeless PAD
implementations, work against one another to kill performance,
when a little more intelligence (on the part of the implementor)
could make it all work passably well.

However, please don't judge X.25 (which is what would be used for
any ISO networking) by the failings of X.3/X.28/X.29 which are
total trash.

Also, if you claim that any standard that allows this behaviour is
no good, then you have just condemned TCP.  TCP is not bound to
deliver any data unless PUSH is set.  I could easily implement
a TAC (PAD) that never set PUSH (or only set PUSH after a timeout,
just to see if any more data is coming...).

kre