Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.dcom.modems
Subject: Re: should i expect MNP4 to be faster than non-MNP?
Message-ID: <44596@lll-winken.LLNL.GOV>
Date: 16 Jan 90 01:33:11 GMT
References: <CHET.90Jan15111149@sparcy.arc.UUCP> <5110@loper.cs.vu.nl>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov (Casey Leedom)
Distribution: comp
Organization: Lawrence Livermore National Laboratory
Lines: 38

| From: rvdp@cs.vu.nl (Ronald vd Pol)
| 
| Both [MNP4 and MNP5] offer a 100% reliable connection.  (So with MNP
| modems you don't need Kermit, just cat the file).

  This is only true if flow control is working at every link point (i.e.
remote computer/modem and local computer/modem.)  For instance, our T2500
modem pool is hooked up to a Vax running 4.3BSD via older Able DMZ32s
(DMF emulators).  Right now we're screwed because 4.3BSD doesn't do
hardware flow control and neither do the DMZ32s.  I'm working on the
software problem and need to call Able again and bug them about an
upgrade to the DMZs which gives me RTS/CTS ...  (For obvious reasons
in band XON/XOFF is out of the question.)

  Thus, even with a reliable link between the two modems, you may still
need to use a reliable end-to-end file transfer protocol because the link
between the two modems isn't the only link in the data transfer path.

  I'll also mention the ongoing argument between ISO and TCP/IP networking
types: ISO type tend to feel that if you have a data communications path
where every link is reliable, then you don't need an end-to-end reliable
protocol.  TCP/IP types have always predicated their protocols on the
fundamental assumption that the individual links in the communication
paths are definitely *NOT* reliable and so have always designed end-to-end
reliable protocols.  But more, TCP/IP types tend to feel that it is the
height of folly to depend on every communication link in a data path
performing reliably, thus they tend to continue to advocate end-to-end
reliable protocols.  Unfortunately (in my view) many TCP/IP types then
turn the above implication around (logically incorrectly) and infer that
reliable links are in themselves not good.  (i.e. They take A -> B and
then say B -> A which is incorrect.  The inverse is really ~B -> ~A.  In
this case A == ``reliable links aren't'' and B == ``thus we need reliable
end-to-end protocols''.)

  In any case, this has strayed totally from the original point.  I now
return you to your regular programming ...

Casey