W8SDZ@SIMTEL20.ARPA (Keith Petersen) (07/23/86)
By permission of the publisher...
----
Originally published by Black Box Corporation in the Black Box
COMMUNICATOR. For a free subscription to the COMMUNICATOR, the BLACK
BOX(R) Catalog and/or the Personal BLACK BOX(R) Catalog, call (412)
746-5500 or write: Black Box Corporation, Subscription Department,
P.O. Box 12800, Pittsburgh, PA 15421.
ERROR CORRECTION IN MODEMS... AND THE MNP PROTOCOL
An Interview with Greg Pearson,
the Developer of MNP
******************************************************
"(Error correction in modems) is a transparent solution
to a problem that's been with us all the time -- noisy
telephone lines."
******************************************************
Sending information, minus the errors, is a top priority among data
communicators everywhere. As a result, more and more modems are being
equipped with the MNP link protocol in their firmware. Many people
feel that this is the most effecicent way to eliminate errors in
today's high-speed dial-up communications. And Greg Pearson, MICOM's
Chief Software Development Manager for Analog Products, is one of them.
The MNP Protocol is his brainchild -- the product of Greg Pearson's
attempt to develop a complete protocol, one with several layers that
perform independently of the others. Needless to say, he was
successful.
This issue of the Communicator features a new Black Box modem that
offers the benefits of the MNP error-control protocol. That modem --
the Dial Modem 24+, featured on page 15 of the COMMUNICATOR -- is just
one example of the important place MNP is taking in the future of data
communications.
BBC: In much of your published material on MNP, you've stressed that
MNP has the richest set of protocols -- that it includes both a full-
fledged link protocol as well as higher level protocols like session
and file transfer. To begin our discussion on error correction in
modems, can you tell us what you mean by a "full-fledged link protocol"
-- and then give an overview of the different types of error correcting
techniques?
PEARSON: For one thing, a full-fledged link protocol has to provide
layer independence. By that I mean that it doesn't depend on the layer
above it to operate effectively. Since error-control is offered at the
link protocol layer, it's important that it be independent. And that's
not the case with the X.PC protocol. X.PC is actually a layer 3
protocol that integrates certain aspects of layer 2 from the OSI
Reference Model. If you're a real architectural purest, you wouldn't
do this.
As for the different types of error correcting techniques used for
point-to-point error correction to date, in the hobbyiest world -- or
rather, the retail-oriented market -- three come to mind right away.
They are Xmodem, X.PC and MNP.
In a sense, these three techniques have been used to accomplish the
same work, but in different environments. For example, many personal
computer software packages use the Xmodem protocol for the error-free
transmission of files over a dial-up telephone connection. But if a
user wants to send an error-free file from a PC into TYMNET(R), X.PC
would be used since it's the protocol used by TYMNET. On the other
hand, if you wanted to do the same thing -- that is, send any data
error-free over a dial-up connection -- with the protocol built into
the modems themselves, you would use MNP.
BBC: Can one protocol be replaced by another?
PEARSON: Well, you could use X.PC or MNP in the same application as
the Xmodem protocol. Basically, Xmodem is a very simple technique --
one that's good for file transfer but not for interactive traffic.
And, as I just mentioned, X.PC is a software protocol approach used by
TYMNET. A couple of companies have put X.PC into the firmware of
their modems, but there are some significant disadvantages in doing
that -- and the most noticable to the user is the difference in
throughput. If you take a look at the market, the use of the MNP
error-control protocol in modems is by far the preferred choice. It's
currently used in the products of something like 16 or 18 modem
vendors.
**************************************************
"Imagine sending all of WAR AND PEACE with the
probability of getting only one 1-bit error."
**************************************************
BBC: Can you explain what you mean by throughput?
PEARSON: Yes. When you have a 2400 bps modem without error control,
the user can expect to send 2400 bits per second. When you implement
X.PC in the firmware of that modem, it uses 9% of those 2400 bits per
second for protocol purposes. So you could expect, in the best case,
a throughput that would be 91% of the line speed.
Now when using MNP in the firmware, you have a different situation.
This, for the most part, is due to a feature that I refer to as
"switch-to-sync."
BBC: You talk about this feature in one of your articles, saying that
it's an exclusive advantage of the MNP protocol. Can you explain what
happens as a result of switch-to-sync?
PEARSON: What happens is the transmission starts in the character-
oriented mode -- or asynchronous mode. But if the modems at both ends
of that transmission are equipped with MNP error-correction, the
transmission will switch to bit-synchronous between the modems. As a
result, the transmission is much more efficient.
BBC: How does that affect the through-put of an MNP-equipped modem?
PEARSON: Let me take you through the whole argument. When a user is
connected to a V.22 bis 2400 bps modem, that user is operating in an
asynchronous character mode. For every eight data bits transmitted,
there is a start bit and a stop bit. That means that the user is
sending 240 characters in 2400 bits -- or ten bits per character.
Now, when an MNP error-correcting modem is sending data, it doesn't
send the user's start and stop bits required in the asynchronous mode.
So for every ten bits sent by the user, MNP only sends eight -- i.e.
MNP is sending data 20% more efficiently than the user because it's
sending 20% fewer bits.
As for the bandwidth, MNP uses 11% for protocol mechanisms. So even
though it loses 11% efficiency there, it gains 20% from the switch-
to-sync operation -- and that puts you 9% ahead of the game.
What that all boils down to is that MNP, on an error-free line, will
impose no throughput degradation when built into the firmware of your
modem. And because of the unique switch-to-sync feature, MNP is
functionally like SDLC or HDLC, the two popular synchronous link
layer protocols.
BBC: What does this all mean to the user?
PEARSON: You can have your cake and eat it too. The ideal aspect of
the MNP link protocol is that you can have it either way -- character-
oriented or bit-synchronous. Other protocols give you no options.
BBC: What you're saying, then, is that MNP offers you a lot more
flexibility than other protocols.
PEARSON: That's right. And it has all the classical features of a
layer 2 protocol: it's full-duplexed -- that is, it can send and
receive data at the same time -- it has error detection based on a
very powerful 16-bit CRC, ithas retransmission for error correction,
and it can reliably send a keyboard break signal... all of which
actually makes it more powerful than HDLC.
BBC: You mentioned the 16-bit CRC, or Cyclic Redundancy Check. Can
you explain that? Also, tell us what actually happens in this type of
retransmission error correction. I believe you refer to it as the
'go-back-n' method of correction.
PEARSON: Any protocol, in order to provide an error-free transmission,
must have two things. One -- it has to provide a way for the receiver
to know if an error has occurred. That's error detection. The
technique employed in MNP for this error detection uses a polynomial
function to calculate a 16-bit number which is a function of all the
data sent in a particular message. The MNP error-correcting protocol
then sends those 16-bits at the end of its message.
The receiver -- as it is receiving the message -- calculates its own
version of this 16-bit number. Then it compares its number with the
16-bit number sent with the message. If the numbers are the same, the
message is free from errors. If the numbers are different, an error
has occurred somewhere in the message. That's how errors are detected.
Once an error is detected, the receiver brings the error correction
mechanism provided by the MNP link protocol into play. That correction
mechanism calls for the receiver to send a message back to the sender.
The sender -- recognizing that the last correct message sent before the
error was data message number 'n' -- is cued to go back to the message
following message 'n'. In other words, if the sender has sent five
messages, and the receiver detects an error in message 4, the sender
will 'go back' to message 4 and begin retransmitting information again.
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. As a result,
the chances of an error occurring are actually so small that you can,
in practice, ignore them. Imagine sending all of WAR AND PEACE with
the probability of getting only one 1-bit error. That's what you could
expect from an error-control protocol that uses the 16-bit CRC.
********************************************************
"(MNP) is a very healthy protocol over long-delay
channels, and that's important to dial-up users. You'd
be surprised how many of your local calls today are
being routed over satellite..."
********************************************************
BBC: MNP also has the ability to send a number of messages before any
acknowledgement is required. Can you explain this?
PEARSON: Any link protocol that's going to work well over telephone
lines must have this ability. If you're making a transcontinental call
and it's transmitted by satellite, you don't want to wait for an
acknowledgement from the receiver after each message. That's how
Xmodem works.
What you want to be able to do is send a number of messages at one
time. MNP lets you have up to eight outstanding messages before an
acknowledgement is required. And MNP is designed in such a way that
only under the worst conditions would a sender ever have to wait
between transmissions. It's a very healthy protocol over long-delay
channels, and that's important to dial-up users. You'd be surprised how
many of your local calls today are being routed over satellite or
microwave.
BBC: You've talked about MNP becoming the de facto standard -- the
unofficial standard for dial-up connections. On what factors would
this really depend? How much does the demand for error-controlling,
high-speed modems influence this?
PEARSON: A year ago, there was some question as to whether the V.22
bis 2400 bps modem was really going to take off. I don't think that's
much of an issue anymore. The price of these modems has come way down
-- to the point that a 2400 bps modem can cost less than a Hayes(R)
1200. The higher speed modems are here to stay.
What affect does this have on the demand for error control in modems?
First of all, we're pushing more bits through the same width pipe --
and we're getting more errors as a result. Secondly -- because we're
sending more bits at a time -- whenever we do get an error, it really
clobbers more bits. Finally, there's the way we're sending bits
through the channels. When we get an error, it takes longer for the
modem to recover -- so when you lose one character, you're actually
losing a whole slew of characters.
In short, our communications are much more error sensitive today. And
we have a dramatically increased need to control errors because of
that. A good way of doing that is by putting the protocol right in the
firmware of a modem -- a way that doesn't really interfere with your
through-put.
It's a transparent solution to a problem that's been with us all the
time -- noisy telephone lines.
# # #
-by Betsy Momich
Publications Department
Black Box Corporationjr@CC5.BBN.COM (John Robinson) (08/06/86)
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.