Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CC5.BBN.COM!jr From: jr@CC5.BBN.COM (John Robinson) Newsgroups: mod.protocols Subject: Re: Interview with MNP protocol author Message-ID: <8608052234.AA08855@ucbvax.Berkeley.EDU> Date: Tue, 5-Aug-86 17:09:30 EDT Article-I.D.: ucbvax.8608052234.AA08855 Posted: Tue Aug 5 17:09:30 1986 Date-Received: Wed, 6-Aug-86 02:41:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 130 Approved: protocols@red.rutgers.edu I wish to present some arguments by way of rebuttal to the posted article about Microcom and the MNP protocol. 1. Others have already spoken to this, but I wish to echo it. Microcom is not playing straight with the world by trying to standardize part of what their boxes do, but not the rest. Either the protocols should be in the public domain or not. I advocate the former approach. I feel it is to everyone's benefit, including Microcom's, for this to happen. As far as I know, what their products do is no more than a straightforward extension of existing, standard protocols, i.e. HDLC. If there are ways to improve on the HDLC standard, why not push to incorporate them into the standard. If other companies eventually produce products that provide the now-standard protocols for less cost, the world has benefited. If Microcom perceives this as a threat, they should either stay competitive, or else move on into the role of consultant to these other companies, or license their particular implementation, as a way of generating revenues. The standardization will help the market for the protocols grow, and they should come out ahead. They will still have an advantage in being there ahead of most everyone else. The protocols ought to improve from the inputs of other standards body members during the standardization process. In particular, limitations of the protocols will become well-documented and the ways to tune them more widely known. Again, both Microcom and the world should benefit. The proprietary approach may lock in more customers in the short run, but leads to a proliferation of standards as other companies figure out different, but better under some circumstances, methods to out-spec the competition. The result is a lot of incompatible boxes. This situation exists today with IBM's and the other major manufacturers' proprietary network architectures, but is being solved with the movement towards the ISO protocols. I think the halfway approach is the worst of both worlds, and will lead to the fragmented situation in the long run. I feel the standards world should (and probably will) look askance at a half-standard. 2. MNP protocol should not be advertised as an error-free protocol, any more than any other data link protocol. A separate message on this list has described a situation where a 16-bit CRC has failed to detect certain error patterns of 4 bits over a short-haul modem connection. In addition, only the segment between the MNP boxes is protected; end-to-end protection requires higher-level mechanisms to protect the other links, such as the line from the host computer or terminal to the MNP box, a connection through a public network such as Telenet, or the internal operating system interfaces within the host computer. >> For all practical purposes, the result of the MNP link is error-free >> transmission. Using the 16-bit redundancy check, it will detect every >> error which is 16 bits or smaller, with 100% probability. No! No! No! Any error in an odd number of bits, and all one-, two-, and three- bit errors will be detected. 16 bits in a row which are inverted are detected, yes (I think!), but a sequence of 16 bits in which some bits are in error is NOT necessarily detected. CRCs aren't that good. You could probably justify the cited statement, but it is terribly misleading if he really means "every error consisting of sequential incorrect bits of up to 16 bits in length," since this is among the least likely error patterns. >> As a result, >> the chances of an error occurring are actually so small that you can, >> in practice, ignore them. Again, misleading. Depends on how critical your data is. If you are sending the money wire transactions between the New York Fed and the Washington Fed, you probably don't agree with this statement at all. >> Imagine sending all of WAR AND PEACE with >> the probability of getting only one 1-bit error. This is grandstanding. The real answer depends on the underlying line error rate. If it is 10^-5, which is the phone company's advertised rate for conditioned lines, you should get an undetected error every 10^5*2^16 bits, in round numbers, 6.6 billion bits. But if the error rates rises to 10^-2 for brief bursts, which may happen for one or two minutes a week without hurting the advertised average BER, your chances of an undetected error climb fast. Again, compare the article on RF modems. In later statements, Pearson implies that the 2400 baud modems have a tougher time coping with errors on the line, which would seem to make the 10^-5 error rate assumption optimistic. It seems that the 16-bit CRC really may not provide as good performance as is claimed for 2400-baud operation, and better checking may be warranted in some circumstances. 3. I don't understand the point about layer independence at all. Modems provide a physical connection. MNP protocol-equipped modems provide a better error rate, with a tradeoff in other performance areas. But as modems, they are still physical layer devices since they do not, as far as I know, provide anything but a physical interface to their users. But this is not really the whole story. The modems provide, in effect, a variable data rate, due to the necessity to back up for retransmissions. For this reason, they also require a link protocol between the modem and the attached device, the terminal or host. So the terminal or host must be programmed to stop on command from the modem, which is not necessary for a classical modem. But now we have lost the transparency promised before. So I don't agree that MNP protocol-equipped modems are completely transparent. They may make use of data link protocols on their local cables that are more commonly available, yes, but without such a link level protocol they may ultimately provide worse service to the user. Pearson's answer on this point attacks other competing protocols without supporting the layer independence point at all. The sarcastic remarks about architectural purists only hurt his case. 4. Synchronous protocols are more efficient in eliminating the asynch start and stop bits. Microcom was certainly clever in figuring out how to use this to their advantage. PADs do the same thing. I think, in the long run, a one-line PAD in a box with the modem would be a far more valuable product. And the standards are already in place. I would really like to see a detailed comparison of MNP with X.25/X.32 + X.3/X.28/X.29. I'd pay a little in efficiency to stick with the latter standards. John G. Robinson BBN Communications, Inc. Disclaimer: these are my own statements, but the company would probably agree with me.