home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11136 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  5.1 KB
  1. Xref: sparky comp.dcom.modems:11136 can.uucp:171
  2. Path: sparky!uunet!uunet.ca!xenitec!zswamp!geoff
  3. From: geoff@zswamp.UUCP (Geoffrey Welsh)
  4. Newsgroups: comp.dcom.modems,can.uucp
  5. Subject: Re: UUCP 'g' vs. MNP & V.42
  6. Message-ID: <mN8FoB2w164w@zswamp.UUCP>
  7. Date: Fri, 24 Jul 92 23:31:45 EDT
  8. References: <1992Jul23.180658.20724@eci386.uucp>
  9. Organization: Izot's Swamp
  10. Lines: 88
  11.  
  12. Just the facts so's the folks make the best decisions:
  13.  
  14. woods@eci386.uucp (Greg A. Woods) writes:
  15.  
  16. > MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
  17. > is a link-layer protocol that retries erroneous packets.  Guess what
  18. > -- the don't get along very well!
  19.  
  20.    This is *completely* untrue!  While MNP may increase latency compared to a 
  21. normal link, it does not in any way interfere with the data being sent.
  22. UUCP-g should not have to retry erroneous packets because MNP will correct 
  23. them, but what harm is there in that?  In addition, MNP3 (the base protocol 
  24. usually used on MNP links; MNP4 is an additional feature allowing dynamic 
  25. packet sizing) strips start and stop bits, increasing throughput as much as 
  26. 20% over normal asynchronous links, even after the error correction overhead 
  27. is taken into account. 
  28.  
  29.    There is no harm in using an error-correcing protocol over an 'error-free' 
  30. link (I put that in quotes because MNP guarantees no errors between the 
  31. modems, not no errors between the computers), unless the protocol imposes a 
  32. significant overhead.  Since, in this case, the overhead is more than made up 
  33. for by start and stop bit removal, there is no reason not to use MNP under 
  34. UUCP-g, at least not at 2400 bps where the increased latency should not push 
  35. past the window size.
  36.  
  37. > MNP-5 is a compression scheme.  I don't believe you can have MNP-5
  38. > without also using MNP-4, i.e. don't try to use MNP-5 with UUCP 'g'.
  39.  
  40.    MNP5, like MNP4, requires that one of MNP1 through MNP3 be active.  I am 
  41. not aware of anyone adapting MNP5 to work with any other link layer protocol.
  42.  
  43. > On the other hand, you do want to *allow* (but not force) MNP for
  44. > dial-up, in case it's a human, or co-operating protocol like SL/IP.
  45.  
  46.    Why would you think that SLIP would "co-operate" with MNP while UUCP-g 
  47. would not?!?  Doesn't SLIP also resend lost/corrupted packets?  What, then, is 
  48. the *mechanical* difference between the two?
  49.  
  50. > BTW, so far as I know, the V.42bis compression protocol is quite
  51. > useful in conjunction with UUCP 'g', especially on a modem that does
  52. > local spoofing of the 'g' protocol (such as the T-2500).
  53.  
  54.    But V.42bis is an data compression protocol which, like MNP5 compression, 
  55. must be implemented over a "link-layer" error correction protocol (normally, 
  56. V.42... which, although not compatible with MNP3/4, is functionally 
  57. equivalent).  If V.42 error correction is benign to UUCP-g (and I'm certain 
  58. that, at 2400, it's significantly *beneficial*), then MNP4 must also be.
  59.  
  60.    What you may be confusing this with is the problem when MNP5 gets its hands 
  61. on precompressed data.  MNP5 is a 'dumb' compression protocol in that it does 
  62. not attempt to assess its effectiveness; when sending precompressed data (e.g. 
  63. compressed newsbatches), it can actually *expand* the data rather than 
  64. compress it.  It has therefore been known that, when you are expecting to 
  65. transfer compressed news, you should disable MNP5... but leave MNP4 on.
  66.  
  67.    V.42bis, on the other hand, does in fact keep track of its effectiveness.  
  68. If it detects that it is expanding data, it will actually turns data 
  69. compression off to prevent a negative effect on throughput.  It is therefore 
  70. harmless to leave V.42bis data compression on, no matter what kind of data 
  71. you're sending.
  72.  
  73.    Sadly, few modems are configurable to allow V.42bis data compression but 
  74. not MNP5; USRobotics modems are among those few.
  75.  
  76. > The Addendum for the WorldBlazer talks about the Telebit LZ Data
  77. > Compression scheme, and hints that V.42bis can be used with PEP.  It
  78. > does not say if Tb's LZ is "safe" with pre-compressed data (like LAP-M
  79. > is).  [V.42bis, MNP-5, and LZ are all variants of the Lempel-Ziv
  80. > compression algorithm, though most implementations of MNP-5 *reduce*
  81. > throughput with pre-compressed data, and each have varying degrees of
  82. > efficiency and ratios of compression.]
  83.  
  84.    Correction: MNP5 is *not* a Lempel-Ziv based algorithm.  It is based on the 
  85. Huffman algorithm (a byte frequency based system), while MNP7 performs Huffman 
  86. coding on byte pairs to achieve better compression.  As mentioned above, 
  87. V.42bis (AKA British Telecom Lempel-Ziv, or BTLZ) monitors its effectiveness 
  88. and will shut itself off if it detects that it is expanding data.  LZ 
  89. compression is not inherently "safe" with precompressed (or random) data. 
  90.  
  91.    V.42bis can be adapted to any error correction scheme, as USRobotics 
  92. proved: they implemented it on top of their HST link-layer protocol (which is 
  93. non-standard - I believe an extension of MNP - and includes provision for 
  94. controlling the reversal of the high speed carrier direction).
  95.  
  96.    It's amazing what you can learn from comp.dcom.modems. <grin>
  97.  
  98. Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
  99. geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
  100.