tnixon@hayes.uucp (Toby Nixon) (11/06/90)
In article <1990Nov5.235125.20448@nusdecs.uucp>, rwhite@nusdecs.uucp (0257014-Robert White(140)) writes: > V.32 is basically a "standard" modulation technique w/answer protocol > recommendations. One of the bizzare things about it, however, is that > it dosn't spesify the "inital connect data rate" in the V.32 specs. > Some modems will initally connect at 9600bps and others will start at > 2400bps. In both cases the modems are V.32 compliant. The fast-start > modems fall-back and the slow-start modems fall-forward durring > protocol initiation. You're not talking about V.32 here, you're talking about what we in the CCITT call "Automode" -- the combination of more than one modem standard into a single device, and the rules by which such modems agree upon the highest speed they have in common and connect at that speed. I certainly wouldn't call it "bizarre" that V.32 didn't specify this; V.32 specifies what it specifies, and Automoding is a completely separate issue. Fortunately, both the TIA TR-30 committee in the USA (the US standards committee on modems) and CCITT Study Group XVII are putting the finishing touches on Automode standards. The CCITT standard, which provides for Automoding of V.32, V.22bis, and V.22, will be an appendix to V.32 and V.32bis. The USA standard will include V.32bis, V.32, V.22bis, V.22, V.21, V.23, Bell 212, and Bell 103, and will be undergoing balloting shortly and finalized within a few months. The problem you describe is not a fault of the standards, but due to the fact that manufacturers have "rolled their own" Automode procedures because of the lack of a standard. > V.42 is the ARQ (automatic retransmit request) and protocol > negotiation standard. It is equavilant to mnp1-4 for all purposes. Wrong. V.42 specifies two procotols: a primary protocol in the main body of the standard (known as Link Access Procedure for Modems, or LAPM), and an alternative protocol in an annex which provides backward compatibility with a portion of the installed base of error correcting modems. Although the term "MNP" does not appear ANYWHERE in V.42, this alternative protocol does provide for compatibility with MNP modems (up to class 4). All extensions, such as V.42bis data compression, apply only to the primary protocol (LAPM), and not to the alternative protocol, which is frozen and will not be extended in any way. Modems claiming compliance to V.42 must implement both the primary and alternative protocols. > It does not do any data compression but it does let the modems argue > about life after the connection is established, without disturbing the Actually, LAPM modems are capable of throughput at about 122% of the speed of an equivalent non-error-control modem (e.g., 292cps on a 2400bps modem) due to stripping of start and stop bits. > data flow. I beleive (read "disclaimer") that without the V.42 the > lines will retrain down to lower speeds when disruptive line noise > occurs but the retrain up is much rarer. V.42 says nothing at all about retraining or changing speeds of the underlying modem. > V.42bis is the data compression technique. This technique is/was more > commonly known as "LAPM" and is substancially different than mnp5. LAPM is the primary protocol of V.42. V.42bis data compression is based on the Lempel-Ziv-Welch (LZW) technique, extended by British Telecom and Hayes. > mnp5 data compression will *reduce* the throughput on already > compressed or truely random data. This is because bandwidth is used > to transmit and reinitalize the mnp5 data dictionary. V.42/LAPM does > not have this problem so it is OK to use on already compressed files. The reason that MNP5 can expand already-compressed data is that it is based on a Huffman code with an AVERAGE token size of NINE bits (they vary in size from 4 to 12 bits). If all tokens are used equally, the data will be expanded from 8 to 9 bits per character, for expansion of 12.5%. The data dictionary is never transferred on the line; dictionaries are maintained in parallel by both modems based on the characters transferred. V.42bis can ALSO expand data! However, unlike MNP5, V.42bis includes the capability for the transmitting modem to signal to the receiving modem whether the data being sent is compressed or uncompressed. The transmitting modem may, therefore, include a feedback monitoring system to examine the degree of compression being achieved in the transmitted data, and switch being transmitting the data in compressed or uncompressed form based on its own performance (this was the enhancement to V.42bis provided by Hayes). > As an added bonus, V.42/V.42bis will not send the > automatic-noise-burst durring connect attempts to non V.42/V.42bis > modems. Simplifying most dilaing/login scripts in various > environemnts. V.42 does send a detection sequence from the originating to the answering modem, just like MNP. However, the V.42 sequence is a series of XON characters with alternating parity, instead of the random "garbage" sent in an MNP Link Request frame. This "detection sequence" was determined, through extensive testing, to be more "benign" and less disruptive than the MNP startup. > Remember that V.32, V.42, and V.42bis are all independant of > ehachother as standards (tho 42bis ?may? require 42 don't actually > know on that score) and the combination of all three are your > best-bet. V.42bis is currently standardized for use ONLY in conjunction with V.42 LAPM, so, yes, V.42bis does imply presence of V.42. The CCITT and other organizations are studying the applicability of V.42bis compression to other environments, such as X.25 packet networks and LANs. -- Toby Nixon, Chairman, TIA TR-30.4; Special Rapporteur for Question 14 in CCITT Study Group XVII (and active participant in the development of V.42 and V.42bis) -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net