joel@gould9.UUCP (Joel West) (12/17/85)
Quoting from Computer Systems News, 12/16/85 [(c) 1985 someone or
another]:
MARINA DEL RAY--Modem maker Microcom Inc. last week proposed
[to CCITT] its MNP (Microcom Networking Protocol) error-protection
scheme as an industry standard for error detection and
correction.
...[The company] announced that MNP classes 1, 2, and 3
will be put in the public domain and said the company will
make them available for $100, including full documentation.
Microcom also said current licensses of MNP classes 1,2,
and 3 will receive licenses to the new classes of 4,5 and 6
free of charge. New licensees of MNP will pay about $2500
for the new classes.
[Mumble jumble marketing b.s. "pretty much a de facto standard"]
[Corporate mucky-muck] said that submitting classes 1 through
3 for consideration as a standard would make classes 4, 5 and
6 a standard also "since they are compatible with the other
classes of MNP."
[He] said the only major opposition to the accpetance of MNP
might come from supporters of Tymnet Inc.'s X.PC protocol.
Questions and comments:
1. It still seems as though Microcom is trying to make money on the
standard itself, instead of benefiting more indirectly from
the standard's success (e.g., Tymnet and X.PC)
2. $100 is pretty high for "public domain". If the manuals are
less than 500 pages (remember the "Inside Macintosh"
controversy), they're probably making a good profit margin
on this "public domain" product.
3. What are the chances that this act of selfless generosity
will be accepted?
4. Why would any company pay $2,500 for 4-6, when they can get
1-3 free?
5. Even if it is free, is there any reason why I would want
MNP?
--
Joel West (619) 457-9681
CACI, Inc. Federal, 3344 N. Torrey Pines Ct., La Jolla, CA 92037
{cbosgd,ihnp4,pyramid,sdcsvax,ucla-cs}!gould9!joel
gould9!joel@nosc.ARPAbarry@adelie.UUCP (Barry A. Burke) (12/18/85)
Regarding Microcom's recent MNP announcements, Joel West asks: >Questions and comments: > 1. It still seems as though Microcom is trying to make money on the > standard itself, instead of benefiting more indirectly from > the standard's success (e.g., Tymnet and X.PC) Without as massive an end-user delivery vehicle as Tymnet, Microcom is trying to make money the only way they can. The hope is that the easy availability of MNP will cause the MAJORITY of Modem manufacturers to License MNP, while Tymet's X.PC is targetted more at Software (eg. terminal emulator/file transfer) developers. > 2. $100 is pretty high for "public domain". If the manuals are > less than 500 pages (remember the "Inside Macintosh" > controversy), they're probably making a good profit margin > on this "public domain" product. And what's wrong with making a profit? And try licensing SNA (*ANY* level) for $100. > 3. What are the chances that this act of selfless generosity > will be accepted? Tremendous. Already there's not a single major modem manufacturer (except Hayes) that doesn't have MNP available on at least one modem (er, excuse me- AT&T may not have delivered a modem with MNP either). > 4. Why would any company pay $2,500 for 4-6, when they can get > 1-3 free? Because 4-6 are BETTER. A recent article in Computer Systems News mentioned that levels 4+ have automatic variable-length packet framing (levels 1-3 are fixed at 64 chars). Also, starting at level 5 (I think), data compression is included- Microcom has announced a 4800 baud modem which is really 2400 baud with data compression. Level 6 is for 9600 baud (+?), Microcom has announced intent to provide modems in this sphere, too. The important factor of all this is that higher throughput is available using MNP 4+ using existing modem technology and standards (the DCA FastLink is NOT "standard" technology- it's extremely proprietary). > 5. Even if it is free, is there any reason why I would want > MNP? Probably not unless you manufacture modems. It's not clear whether anything can be gained (or if it's even possible) by running MNP in software in say, your PC's terminal emulator. BUT, if you DO manufacture modems, already it appears to be in your best interest to invest in and implement MNP, since a growing percentage of the 2400+ baud modems are using it. And if (as I suspect) MNP works BETTER for interactive use than does the FastLink stuff at higher speeds- look out, EVERYBODY will have MNP. [Disclaimer: I have no interest or relationship with Microcom, etc.] [ I provide no warrent, expressed or otherwise, that the] [ above information is correct. ] -- LIVE: Barry A. Burke, (617) 965-8480 x26 USPS: Adelie Corporation, 288 Walnut St., Newtonville, MA 02160 UUCP: ..!{harvard | decvax!linus!axiom}!adelie!barry ARPA: adelie!barry@harvard.HARVARD.EDU, barry%adelie.UUCP@harvard.HARVARD.EDU
faunt@hplabs.UUCP (Doug Faunt) (12/19/85)
> > It's not clear whether > anything can be gained (or if it's even possible) by running MNP in > software in say, your PC's terminal emulator. BUT, if you DO Is this true? If so, why? Is there something simple here that I don't see? -- ....!hplabs!faunt faunt%hplabs@csnet-relay.ARPA HP is not responsible for anything I say here. In fact, what I say here may have been generated by a noisy telephone line.
ralphw@ius2.cs.cmu.edu (Ralph Hyre) (12/21/85)
In article <1956@hplabs.UUCP> faunt@hplabs.UUCP (Doug Faunt) writes: >> >> It's not clear whether >> anything can be gained (or if it's even possible) by running MNP in >> software in say, your PC's terminal emulator. BUT, if you DO > >Is this true? If so, why? Is there something simple here that I don't >see? Well, there's and end-to-end argument in computer systems design* which claims that it's often useful to put error correction in the application itself rather than depend on error correction at lower levels, since the low-level correction doesn't know all the ways in which the higher-level applications can lose or corrupt data. MNP might get the bits back and forth between the modems ok, but then you have to make sure that the modem <-> computer (memory) <-> filesystem connection is reliable. (Generally it is, so most people will be happy with MNP and X.PC if they're not to paranoid) This would argue for putting MNP closer to the application itself. In general, it's best to just to do error correction in just one place unless the underliying communications channels are flaky enough to require it (some LD phone lines are certainly an example of this.) * recommended reading, it's in an ACM Transacions on (Computer Systems?) journal that came out recently, written by two of the following people: {Jerry Saltzer, Dave Clark, Dave Reed} The careful file transfer discussion is very relevant. -- - Ralph W. Hyre, Jr. Internet: ralphw@c.cs.cmu.edu (cmu-cs-c.arpa) Usenet: ralphw@mit-eddie.uucp Fido: Ralph Hyre at Net 129, Node 0 (Pitt-Bull) Phone: (412)578-2847,578-3275 -- - Ralph W. Hyre, Jr. Internet: ralphw@c.cs.cmu.edu (cmu-cs-c.arpa) Usenet: ralphw@mit-eddie.uucp Fido: Ralph Hyre at Net 129, Node 0 (Pitt-Bull) Phone: (412)578-2847,578-3275
karn@petrus.UUCP (Phil R. Karn) (12/21/85)
Personal opinion: Whenever possible, and unless your lines are VERY noisy, you should ignore this "reliable link level protocol" garbage and run TCP/IP with serial-line-IP (SLIP) across your simple dialup modems. If your TCPs are properly tuned and implement the Nagle congestion control algorithm, Telnet works very nicely. Plus you get transparent Internet access with full end-to-end error checking (something a link protocol can't do) to boot. If you have a PC, you can use the MIT package. Maybe some day an enlightened vendor will come out with a cheap, single-port TCP/IP/SLIP "PAD" that works instead of reinventing yet another ad-hoc, "proprietary" link level protocol. Phil
lauren@vortex.UUCP (Lauren Weinstein) (12/22/85)
Actually, the problems of computer<->modem data integrity are quite serious, especially at higher speeds (but sometimes as low as 1200 bps) and especially with hardware and operating systems which tend to have problems with "high" speed serial data (like many computers which run Unix, for example). --Lauren--
faunt@hplabs.UUCP (Doug Faunt) (12/23/85)
> In article <1956@hplabs.UUCP> faunt@hplabs.UUCP (Doug Faunt) writes: > >> > >> It's not clear whether > >> anything can be gained (or if it's even possible) by running MNP in > >> software in say, your PC's terminal emulator. BUT, if you DO > > > >Is this true? If so, why? Is there something simple here that I don't > >see? > > > This would argue for putting MNP closer to the application itself. > In general, it's best to just to do error correction in just one place > unless the underliying communications channels are flaky enough to > require it (some LD phone lines are certainly an example of this.) > I may have been misunderstood here. The original statement was > >> It's not clear whether > >> anything can be gained (or if it's even possible) by running MNP in > >> software in say, your PC's terminal emulator. My question was (intended to be), can I run MNP in software if I have a terminal emulator running on a general-purpose computer system? or is MNP hard-tied into the data-transmission circuits/algorithms in the modem? Ralph's reply, which makes sense to me, seems to say that running any error-correction protocol "closer" to the application is a good thing. This would mean that running MNP in my terminal emulator would be a good thing. -- ....!hplabs!faunt faunt%hplabs@csnet-relay.ARPA HP is not responsible for anything I say here. In fact, what I say here may have been generated by a noisy telephone line.
barry@adelie.UUCP (Barry A. Burke) (12/24/85)
>> >> It's not clear whether >> >> anything can be gained (or if it's even possible) by running MNP in >> >> software in say, your PC's terminal emulator. > > My question was (intended to be), can I run MNP in software >if I have a terminal emulator running on a general-purpose computer system? >or is MNP hard-tied into the data-transmission circuits/algorithms in >the modem? > >Ralph's reply, which makes sense to me, seems to say that running >any error-correction protocol "closer" to the application is >a good thing. This would mean that running MNP in my terminal emulator >would be a good thing. > I obviously was not very explicit in my original posting regarding the above statement. What I am saying is that MNP is quite likely a time-based correction protocol, as it was developed to run on modem hardware (as opposed to X.PC, which was designed to run in the PC itself). To maintain the high throughput of MNP (it's effectively transparent on clean lines- low overhead), I suspect that a time-synchronous factor is included in the missed packet/packet framing componenet of MNP. This would enable packets to be simply framed and checksummed. X.PC, on the otherhand, must have a much more X.25-like framing in order to handle multiple sessions over the link. What I'm driving at is that MNP is a reasonably effective and efficient error correction protocol for the physical layer, but it probably can't well be implemented in software on a GP PC or timesharing system, because of it's origin as a component of a piece of comms hardware. Running MNP in userspace on your VAX might be much like running SDLC without any hardware to help- good luck. And while I agree that error correction (and recovery) really must be done at the application level, error recovery at lower levels can reduce the overal data-flow overhead, as the higher up the problems must be RECOVERED from, the more the overhead to perform the recovery (note that the DETECTION overhead is predictably constant at each level). So, for me, I'd prefer the following (as an example): PC Remote HOST ============ =========== APPLICATION <--- (Appl. ERROR CORRECTION) ---> APPLICATION CLIENT SERVER v v v v X.PC <--- (X.PC ERROR CORRECTION) ---> X.PC CLIENT [running on Host CPU] SERVER v v v v MNP <--- (MNP ERROR CORRECTION) ---> MNP MODEM [running in Modems] MODEM v v v v - - - - - - - - - - - - - - -/ /- - - - - - - - - - - - - Too much of today's Application software assumes clean, clear data transfer to/from the remote device- a case that's not even 99% true for direct connect devices, much less anyhting that connectes over phone lines. MNP (in my opinion) tries to make the phone lines look clear, but do NOT protect from every data error the Application may see. Likewise, X.PC (I've worked for years over X.25 links- the only thing that's assured is that whatever garbage you put in one side will come out the other, in the right order!). If you want error-free, you have to do error correction at the application. BUT since pending flushes, data re-packetizing, and retransmission is expressed in CPU & memory use overhead- you'll get a better PERFORMING package if you use a recovery protocol at several different layers. Remember, the best performing error recovery implementation is one that costs nothing to detect errors, and never has to correct any! -- LIVE: Barry A. Burke, (617) 965-8480 x26 USPS: Adelie Corporation, 288 Walnut St., Newtonville, MA 02160 UUCP: ..!{harvard | decvax!linus!axiom}!adelie!barry ARPA: adelie!barry@harvard.HARVARD.EDU, barry%adelie.UUCP@harvard.HARVARD.EDU
mark@cbosgd.UUCP (Mark Horton) (12/28/85)
For true HOST-HOST communication, ala TCP/IP or UUCP or X.25 or OSI or whatever, there are end-to-end protocols that make things like MNP unnecessary (and the overhead could hurt throughput.) But for ordinary RS232 "lowest common denominator" terminals, especially over possibly noisy dialup lines, MNP could be a big win. But it's not perfect - lack of flow control can still cause you to drop data if the producer creates bursts that the consumer can't handle in real time. I'm not very familiar with MNP, but I seem to recall hearing that it uses the start and stop bits (recall that async links send 10 bits for each 8 bit character, using start and stop for framing) for the extra information. This means there is no slowdown. It also means that you cannot send a BREAK over such a line, and I seem to recall hearing someone saying that you can't send a BREAK with MNP. This only matters for users of terminals, since host protocols don't generally use BREAK, but then the terminal users are the ones who benefit most from MNP. Mark
johnl@ima.UUCP (01/02/86)
There seems to be some confusion as to whether it is possible to implement MNP on a regular computer, rather than in the modem. The answer seems to be yes, since I am at this moment typing on an IBM PC running a modem program from Microcom which implements MNP with (I think) no help from the modem. MNP is actually a family of protocols, including reliable link mode, which is like Telnet, and reliable file transfer which is like FTP. The reliable link mode does seem not to allow breaks, and is a little spazzy in very interactive use. I usually use it when dialing into Telenet, logging in to some computer and having it blat a lot of data at me, which works well. The file transfer mode works great and seems to be faster than any other commonly available PC protocol. (RBBS-PC, a common bulletin board program, supports it.) It's a big win over XMODEM. There are also features that I don't really understand which are supposed to help when transferring files between computers that have different opinions about e.g. end of line characters. John Levine, ima!johnl
henry@utzoo.UUCP (Henry Spencer) (01/03/86)
> And while I agree that error correction (and recovery) really must be > done at the application level, error recovery at lower levels can reduce > the overal data-flow overhead, as the higher up the problems must be > RECOVERED from, the more the overhead to perform the recovery... Note the key word "can", not "will". Upper levels sometimes need do *less* work to perform recovery, because they know more about what's going on. An extreme case is packet voice, where it is usually better *not* to attempt recovery at all, because the delay involved in recovery is much more audible than just forgetting the bad packet altogether and faking it until the next good one arrives. (How to "fake it"? Repeat the last packet. Or hold the sound output constant at the last value of the last packet. Or do any of several more complicated things. All less audible than a gap.) Also don't forget that layered protocols can exact a terrible price in performance, because of multiple layers of overhead. If your lines are noisy and your performance needs are both moderate and orthodox, low-level recovery is probably a win even though one does need end-to-end checks as well. If you care a lot about performance and your transmission medium is pretty good (e.g. Ethernet), the situation looks very different. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry