From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.dcom.modems,can.uucp
Subject: Re: UUCP 'g' vs. MNP & V.42
Date: Fri, 24 Jul 92 23:31:45 EDT
Organization: Izot's Swamp

Just the facts so's the folks make the best decisions:

woods@eci386.uucp (Greg A. Woods) writes:

> MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
> is a link-layer protocol that retries erroneous packets.  Guess what
> -- the don't get along very well!

   This is *completely* untrue!  While MNP may increase latency compared to a 
normal link, it does not in any way interfere with the data being sent.
UUCP-g should not have to retry erroneous packets because MNP will correct 
them, but what harm is there in that?  In addition, MNP3 (the base protocol 
usually used on MNP links; MNP4 is an additional feature allowing dynamic 
packet sizing) strips start and stop bits, increasing throughput as much as 
20% over normal asynchronous links, even after the error correction overhead 
is taken into account. 

   There is no harm in using an error-correcing protocol over an 'error-free' 
link (I put that in quotes because MNP guarantees no errors between the 
modems, not no errors between the computers), unless the protocol imposes a 
significant overhead.  Since, in this case, the overhead is more than made up 
for by start and stop bit removal, there is no reason not to use MNP under 
UUCP-g, at least not at 2400 bps where the increased latency should not push 
past the window size.

> MNP-5 is a compression scheme.  I don't believe you can have MNP-5
> without also using MNP-4, i.e. don't try to use MNP-5 with UUCP 'g'.

   MNP5, like MNP4, requires that one of MNP1 through MNP3 be active.  I am 
not aware of anyone adapting MNP5 to work with any other link layer protocol.

> On the other hand, you do want to *allow* (but not force) MNP for
> dial-up, in case it's a human, or co-operating protocol like SL/IP.

   Why would you think that SLIP would "co-operate" with MNP while UUCP-g 
would not?!?  Doesn't SLIP also resend lost/corrupted packets?  What, then, is 
the *mechanical* difference between the two?

> BTW, so far as I know, the V.42bis compression protocol is quite
> useful in conjunction with UUCP 'g', especially on a modem that does
> local spoofing of the 'g' protocol (such as the T-2500).

   But V.42bis is an data compression protocol which, like MNP5 compression, 
must be implemented over a "link-layer" error correction protocol (normally, 
V.42... which, although not compatible with MNP3/4, is functionally 
equivalent).  If V.42 error correction is benign to UUCP-g (and I'm certain 
that, at 2400, it's significantly *beneficial*), then MNP4 must also be.

   What you may be confusing this with is the problem when MNP5 gets its hands 
on precompressed data.  MNP5 is a 'dumb' compression protocol in that it does 
not attempt to assess its effectiveness; when sending precompressed data (e.g. 
compressed newsbatches), it can actually *expand* the data rather than 
compress it.  It has therefore been known that, when you are expecting to 
transfer compressed news, you should disable MNP5... but leave MNP4 on.

   V.42bis, on the other hand, does in fact keep track of its effectiveness.  
If it detects that it is expanding data, it will actually turns data 
compression off to prevent a negative effect on throughput.  It is therefore 
harmless to leave V.42bis data compression on, no matter what kind of data 
you're sending.

   Sadly, few modems are configurable to allow V.42bis data compression but 
not MNP5; USRobotics modems are among those few.

> The Addendum for the WorldBlazer talks about the Telebit LZ Data
> Compression scheme, and hints that V.42bis can be used with PEP.  It
> does not say if Tb's LZ is "safe" with pre-compressed data (like LAP-M
> is).  [V.42bis, MNP-5, and LZ are all variants of the Lempel-Ziv
> compression algorithm, though most implementations of MNP-5 *reduce*
> throughput with pre-compressed data, and each have varying degrees of
> efficiency and ratios of compression.]

   Correction: MNP5 is *not* a Lempel-Ziv based algorithm.  It is based on the 
Huffman algorithm (a byte frequency based system), while MNP7 performs Huffman 
coding on byte pairs to achieve better compression.  As mentioned above, 
V.42bis (AKA British Telecom Lempel-Ziv, or BTLZ) monitors its effectiveness 
and will shut itself off if it detects that it is expanding data.  LZ 
compression is not inherently "safe" with precompressed (or random) data. 

   V.42bis can be adapted to any error correction scheme, as USRobotics 
proved: they implemented it on top of their HST link-layer protocol (which is 
non-standard - I believe an extension of MNP - and includes provision for 
controlling the reversal of the high speed carrier direction).

   It's amazing what you can learn from comp.dcom.modems. <grin>

Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467