http://groups.google.com/d/topic/comp.dcom.modems/8ovkVeNkGHc/discussion
`comp.dcom.modems ›
`Telebits "PEP" protocol
`25 posts by 16 authors
`Mark Montgomery
`12/7/90
`I have been somewhat daunted by the recently explosive growth of info
`on high(er) speed modems in this group. One question that comes to
`mind is why isn't some modem manufacturer that already has a handle
`on V.32, V.42, bis, etc putting PEP into their products? Seems like
`that would not only be a good marketing boost but also give some
`competition to Telebit who seems to own the Unix connectivity market.
` Just a thought, Mark
`Click here to Reply
`Marc Unangst
`12/10/90
`ncp...@brahms.amd.com (Mark Montgomery) writes:
`> mind is why isn't some modem manufacturer that already has a handle
`> on V.32, V.42, bis, etc putting PEP into their products? Seems like
`> that would not only be a good marketing boost but also give some
`> competition to Telebit who seems to own the Unix connectivity market.
`Mostly because Telebit also owns the PEP protocol. They invented it,
`and they can decided who gets to use it. I believe Telebit is
`behaving like Microcom, who refused to license the MNP protocols above
`5 to other manufacturers, preferring to have all of a small pie than a
`smaller piece of a big pie.
`Also, there are superior protocols. Even though PEP holds a noisy
`line very well, it is mostly half-duplex, and other protocols such as
`V.32bis will beat it out for raw throughput most of the time. PEP is
`also not so good for interactive use (see HDX note above). When PEP
`was invented, it was great -- and it still is great for some
`applications. But I don't think the sales would be large enough for
`another company to justify licensing the protocol from Telebit, even
`if Telebit was willing.
`--
`Marc Unangst |
`m...@mudos.ann-arbor.mi.us | "Bus error: passengers dumped"
`...!umich!leebai!mudos!mju |
`dcau...@cdp.uucp
`12/11/90
`Telebit's PEP protocol is both proprietary and patented.
`It is possible that Telebit might license other manufacturers, but
`I suspect they would not do so unless they saw this as increasing
`their net revenues.
`Telebit people read comp.dcom.modems - maybe they will comment.
`Dave C
`Geoff Steckel - Sun BOS Hardware
`12/11/90
`In article <8sHZT...@mudos.ann-arbor.mi.us> m...@mudos.ann-arbor.mi.us (Marc Unangst)
`writes:
`>ncp...@brahms.amd.com (Mark Montgomery) writes:
`>> mind is why isn't some modem manufacturer that already has a handle
`>> on V.32, V.42, bis, etc putting PEP into their products? Seems like
`>> that would not only be a good marketing boost but also give some
`>> competition to Telebit who seems to own the Unix connectivity market.
`Mostly because Telebit also owns the PEP protocol. They invented it,
`
`>>
`
`Page 1 of 19
`
`

`
`>and they can decided who gets to use it.
`Does anybody remember Vadic (now Racal-Vadic) 1200 bps modems?
`They were the first (and still technically superior to Bell 212)
`full duplex 1200 bps modems. Vadic refused to license any of the
`protocols. Bell announced 212, and after a couple of years, released
`it for general use. Result: Vadic was incompatible with all the other
`1200 bps units, and that protocol died as a result. It was a pity
`at the time, since Bell picked 2 carrier frequencies which were
`harmonically related and interfered with each other if line distortion
`was high.
`Open letter to Telebit: if you think PEP is worth anything, licence
`it (with or without fee). Otherwise it will be bypassed by a (possibly
`inferior) but widely available standard. V.32 is coming up fast.
`Anecdote: until the patents run (ran?) out, Phillips N.V. collects a
`very small (apocryphally $.05) royalty on all audio cassettes. They also
`refuse to allow any modification to cassette designs which will cause
`incompatibility. They will licence to anybody, anywhere, cheaply.
`Result: Phillips survives immense losses on practically
`all its other products. Cassettes are the largest selling recorded
`music medium.
` geoff steckel (gw...@wjh12.harvard.EDU)
` (...!husc6!wjh12!omnivore!gws)
`Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
`This posting is entirely the author's responsibility.
`Casey Leedom
`12/11/90
`| From: gste...@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware)
` >From: m...@mudos.ann-arbor.mi.us (Marc Unangst)
`| >
`| >>From: ncp...@brahms.amd.com (Mark Montgomery)
`| >>
`| >> ... why isn't some modem manufacturer that already has a handle
`| >> on V.32, V.42, bis, etc putting PEP into their products?
`| >
`| >Mostly because Telebit also owns the PEP protocol. They invented it,
`| >and they can decided who gets to use it.
`
`||
`
`||
`
` Open letter to Telebit: if you think PEP is worth anything, license it
`| (with or without fee). Otherwise it will be bypassed by a (possibly
`| inferior) but widely available standard. V.32 is coming up fast.
` Telebit's DAMQAM (Dynamic Adaptive Multicarrier Quadrature Amplitude
`Modulation) has a couple of definite features over V.32 and possibly even
`the upcoming V.32bis standard:
` o Ability to handle line noise and changing line conditions.
` o Higher raw bandwidth -- in one direction at a time.
`From what I understand, PEP (Packetized Ensemble Protocol) is simply a
`special packetizing and error detection/correction protocol designed to
`live on top of DAMQAM and provide a simulated full duplex interface. The
`spoofing of various higher level protocols to increase overall throughput
`rates are a completely separate issue and could be layered on top of any
```error free'' channel.
` The protocol spoofing is nice, but mostly a because of stupidity in the
`higher layer protocols -- notably a fixed window size of 1. (From what I
`understand, SLIP spoofing, when it becomes available, will actually be
`making up for the half duplex nature of DAMQAM.) Nevertheless, in this
`world of stupid higher level protocols, the spoofing is a definite
`advantage. My only complaint is that I should be able to do it over any
```error free'' channel, such as V.32/V.42/V.42bis.
` PEP is simply a packetization protocol. Who cares? Please feel free
`to flame me if I'm misstating the extent of PEP's features.
` But, the real winner is DAMQAM. After struggling with a V.32
`
`Page 2 of 19
`
`

`
`connection for the last couple of weeks with the best length of connection
`being ninety minutes I've changed my mind about telling people to forget
```PEP'' modems and just go with V.32.
` My only problem is I can't stand using PEP. The echo delays are
`terrible to behold when I try to use my X terminal and it's just barely
`passable with a normal terminal. Visual editors are gruesome.
` It would be really nice if Telebit could come up with a follow on to
`DAMQAM that was ``TRUE'' full duplex ala the V.32/V.32bis echo
`cancellation. Really nice. Incredible nice. Can you imagine it?
`Roughly 18Kbps full duplex and reliable over the worst lines? Layer
`V.42/V.42bis on top of that and you'd have one mean communications link
`... such a modem would also, of course, have to support ``TRUE''
`38.4Kbps ... :-)
` Oh course, in line with the note that I'm following up, it would have
`to be licensed very cheaply for such a scheme to become widely used or
`adopted as a new CCITT standard ...
`Casey
`Bob Sutterfield
`12/12/90
`In article <87...@lll-winken.LLNL.GOV> ca...@gauss.llnl.gov (Casey Leedom) writes:
` I should be able to do [protocol spoofing] over any ``error free''
` channel, such as V.32/V.42/V.42bis.
`According to the T2500 firmware version GE7.00 release notes,
` Protocol Support in V.32 Mode
` All file transfer protocols defined by the S111
` register are now supported when a MNP connection is
` established in V.32 mode.
`No mention (yet?) of spoofing support over a V.42/V.42bis connection.
`Cerafin E Castillo
`12/12/90
`Casey quotes and writes:
`| Open letter to Telebit: if you think PEP is worth anything, license it
`| (with or without fee). Otherwise it will be bypassed by a (possibly
`| inferior) but widely available standard. V.32 is coming up fast.
`Telebit does license PEP/DAMQAM in an 18 kbps non-LZ compression (No S110)
`form to Ventel (ie Ventel Pathfinder) and Racal-Milgo (1822S). Various
`form factors have also been available in the DCA Fastlink, GTE TrailBlazer,
`etc., mostly OEM-type deals.
`>Telebit's DAMQAM (Dynamic Adaptive Multicarrier Quadrature Amplitude
`>Modulation) has a couple of definite features over V.32 and possibly even
`>the upcoming V.32bis standard:
` o Ability to handle line noise and changing line conditions.
` o Higher raw bandwidth -- in one direction at a time.
`This is true. the one direction at a time (half-duplex / "adaptive duplex)
`is a benefit, as well as a problem, especially in interactive work.
`> The protocol spoofing is nice, but mostly a because of stupidity in the
`>higher layer protocols -- notably a fixed window size of 1.
`Correct. In UNIX UUCP ('g' protocol), the window size is usually a fixed size
`of 3. SCO UNIX and other such O/S UUCPs have adjustable sizings up to 7 for
`use with slower (<= V.32) modems. PEP forces a window size of 3, then performs
`the spoof at each end in order to be able to do the PEP/DAMQAM (half-duplex)
`modulation between the two modems without causing the full duplex 'g' protocol
`to timeout. Both a necessity and a feature! This comes in handy with UUPC,
`Waffle, or other such DOS programs with a window size of 1. The spoof will
`automatically make this software do a 3 window size and effect performance
`radically (if the serial I/O drivers can hack it! ;-).
`>(From what I understand, SLIP spoofing, when it becomes available, will
`>actually be making up for the half duplex nature of DAMQAM.)
`
`>>
`
`>>
`
`Page 3 of 19
`
`

`
`SLIP spoofing, from what Telebit has told me, will never exist. the Telebit
`NetBlazer is the current SLIP/CSLIP/PPP solution offered by Telebit.
`As to protocol spoofing:
`>My only complaint is that I should be able to do it (protocol spoofing)
`>over any ``error free'' channel, such as V.32/V.42/V.42bis.
`You can. The current GF7.00 firmware for T2500/T1500 allows protocol support
`in V.32 (with or without V.42/V.42bis) between Telebit modems (ONLY!). The
`New, T1600 modem is also capable of doing this. From my test of this firmware
`feature, it is not very impressive. Maybe a 10% gain over raw V.32 throughput.
`> PEP is simply a packetization protocol. Who cares? Please feel free
`>to flame me if I'm misstating the extent of PEP's features.
`No problem. PEP is a sales/marketing term for the layman. DAMQAM is the
`correct modulation method. PEP is just an ECC layer.
`> But, the real winner is DAMQAM.
`>After struggling with a V.32 connection for the last couple of weeks...
`>I've changed my mind about telling people to forget ``PEP'' modems and
`>just go with V.32.
`I have to agree. V.32, and for that fact V.32bis or V.32turbo (Rockwell
`option) all using single carrier technology and echo cancellation/trellis
`techniques, are only as good as the line you are using them on. While
`this is true for DAMQAM as well, the multicarrier technology assures that
`you will find available carriers for your data on any phone line (except a
`dead one...;-) amongst the 511 carriers it makes avaialble. Furthermore,
`you will be able to move anywheres from 2,4, or 6 bits of data through
`these carriers at speeds between 7.3 and 88.26 baud. Of course, those of
`you who know about the hidden registers (See Telebit Tech Support for
`documentation...) also know of how to squeeze even more throughput out
`of a bad line using DAMQAM packetization modification methods. 38.4 kbps
`is available on the T1600.
`> My only problem is I can't stand using PEP. The echo delays are
`>terrible to behold when I try to use my X terminal and it's just barely
`>passable with a normal terminal. Visual editors are gruesome.
`I agree. I use V.32 with V.42bis compression in the receive direction
`when using a Graphon OptimaX 200 X-Windows solution. Since the mouse
`and typing yielded small bits of data as opposed to the screen redraws
`coming in from the system, this method worked well, but not always
`reliably. This was due to the combination of V.32 line problems. PEP
`was very frustrating to deal with and could not provide this level of
`intelligence in handling data on a per carrier basis.
`> It would be really nice if Telebit could come up with a follow on to
`>DAMQAM that was ``TRUE'' full duplex...
`>support ``TRUE'' 38.4Kbps ... :-)
`V.34 Asym seemed to have died in CCITT. This was the proposal for a 28 Kbps
`PEP with a reverse 300-600 channel. Maybe in light of multicarrier cellular,
`satellite, microwave, or fax modulation methods, it might be given new life...
`I hope these personal and technical insights help. As a Telebit modem user
`I share the same problems and complaints, but have the added benefit of a
`little more product education thanks to Telebit.
`===============================================================================
`Cerafin E. Castillo || //\\ ||\\ ||
`Network Consultant || //__\\ || \\ || Los Altos
`Los Altos Networks || // ---\\|| \\|| Networks
`340 Second St. #6 ||___// \ | \ |
`Los Altos, CA 94022
`(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
` INTERNET: c...@cup.portal.com
` "...No hay mal que por bien no venga..."
`===============================================================================
`
`Page 4 of 19
`
`

`
`Casey Leedom
`12/13/90
`| From: c...@cup.portal.com (Cerafin E Castillo)
`
`||
`
` >| Open letter to Telebit: if you think PEP is worth anything, license it
`| >| (with or without fee). Otherwise it will be bypassed by a (possibly
`| >| inferior) but widely available standard. V.32 is coming up fast.
` Telebit does license PEP/DAMQAM in an 18 kbps non-LZ compression (No S110)
`| form to Ventel (ie Ventel Pathfinder) and Racal-Milgo (1822S). Various
`| form factors have also been available in the DCA Fastlink, GTE TrailBlazer,
`| etc., mostly OEM-type deals.
` Since I expect that V.42bis is probably nearly as good or better than
`PEP's LZ compression, the lack of compression isn't a problem except that
`Telebit doesn't support V.42/V.42bis on top of DAMQAM (you'd actually
`have to have a layer between performing the adaptive-(sic)-duplex, but
`that's just an implementation issue.) By withholding their LZ compression
`it sounds like Telebit was just trying to prevent its licensees from
`being competitive with Telebit's products. This just emphasizes the
`earlier poster's point.
` I also agree with another poster who mentions the Phillips Cassette as
`an example. I'd bet that if Telebit were to cheaply license their
`technology out for, say, $5 a modem to any and all comers, a CCITT
`standard would be rapidly forthcoming and Telebit would be amazed at how
`much money they made without even making product ...
`| >Telebit's DAMQAM (Dynamic Adaptive Multicarrier Quadrature Amplitude
`| >Modulation) has a couple of definite features over V.32 and possibly even
`| >the upcoming V.32bis standard:
`| >
`| > o Ability to handle line noise and changing line conditions.
`| >
`| > o Higher raw bandwidth -- in one direction at a time.
`
`||
`
`||
`
` This is true. The one direction at a time (half-duplex / adaptive-duplex)
`| is a benefit, as well as a problem, especially in interactive work.
` Except that half-duplex/adaptive-duplex is not the reason for DAMQAM's
`robustness with regard to line problems. Multi-carrier technology is.
`You all but say this later on, but I think it's important to stress it
`here.
` As for the half-duplex nature of DAMQAM ... I mostly count that as a
`massive headache with higher single direction bandwidth offered as a
`salve.
` I used to complain bitterly about the fixed receive/transmit channel
`allocation (essentially half-duplex) and ask why Telebit hadn't used
`dynamic channel allocation based on measured receive/transmit loads.
`Recently I heard a rumor that Telebit was working on a new multi-carrier
`technology that used echo cancellation on each of the sub-carriers to
`produce ``TRUE'' full-duplex. I would really love to see this happen.
`| > The protocol spoofing is nice, but mostly a because of stupidity in the
`| >higher layer protocols -- notably a fixed window size of 1.
`
`||
`
` In UNIX UUCP ('g' protocol), the window size is usually a fixed size of
`| 3. SCO UNIX and other such O/S UUCPs have adjustable sizings up to 7 for
`| use with slower (<= V.32) modems. PEP forces a window size of 3, then
`| performs the spoof at each end in order to be able to do the PEP/DAMQAM
`| (half-duplex) modulation between the two modems without causing the full
`| duplex 'g' protocol to timeout.
` Actually UUCP (really uucico) is 100% half-duplex. It only transmits
`files in one direction at a time. The big problem with the UUCP 'g'
`protocol and PEP modems is that the ACK packets are big enough to cause
`the line to turn around introducing huge delays for each packet. Since
`the data packets are very small this drops your throughput a lot. The
`other advantage of spoofing that I mentioned earlier is that it helps
`keep the data pipeline loaded when protocols using small windows are used
`on long delay links.
`
`Page 5 of 19
`
`

`
`| >My only complaint is that I should be able to do it (protocol spoofing)
`| >over any ``error free'' channel, such as V.32/V.42/V.42bis.
`
`||
`
` You can. The current GE7.00 firmware for T2500/T1500 allows protocol
`| support in V.32 (with or without V.42/V.42bis) between Telebit modems
`| (ONLY!). The New, T1600 modem is also capable of doing this. From my
`| test of this firmware feature, it is not very impressive. Maybe a 10%
`| gain over raw V.32 throughput.
` My mistake -- I should have read the manual. I would expect it to work
`only with other Telebits since I don't know of any other modems that
`implement spoofing of any kind (I expect that the Ventels using licensed
`Telebit technology may spoof protocols, but even if they do they wouldn't
`have gotten the new code from Telebit yet.)
` As for it's impressiveness, which protocols did you try? My bet is that
`you only tried UUCP 'g' protocol. With a full-duplex data path, the only
`advantage that spoofing could offer would be to keep the pipeline full.
`If there's not much delay in the total link, even UUCP 'g's 3 packet
`window should do okay at that.
` On the other hand, I'd expect to see a lot of improvement for the 1
`packet window protocols for kermit and xmodem.
`| >(From what I understand, SLIP spoofing, when it becomes available, will
`| >actually be making up for the half duplex nature of DAMQAM.)
` SLIP spoofing, from what Telebit has told me, will never exist. the
`| Telebit NetBlazer is the current SLIP/CSLIP/PPP solution offered by
`| Telebit.
` I'm really going to have to look at that product. I'm beginning to
`think that it might be the right thing to use for tele-commuting ... On
`the other hand, it would still be slave to the underlaying modem
`technology and I think that my comments above and in my previous posting
`point out my feelings on this with regard to DAMQAM.
`| ... Of course, those of you who know about the hidden registers (See
`| Telebit Tech Support for documentation...) also know of how to squeeze
`| even more throughput out of a bad line using DAMQAM packetization
`| modification methods. 38.4 kbps is available on the T1600.
` But is there any help for the half-duplex nature of DAMQAM. I mean,
`I'm not just relating third hand hearsay. I'm typing over it right this
`second and I can't stand it. If the line quality between my new house
`and my work were better I'd never use DAMQAM.
` I can only hope that the rumors I've heard are true and that we'll see
`a new version of DAMQAM coming out of Telebit. And of course, in line
`with the my previous posting and the posting I was following up at that
`time, I hope that Telebit promises to license the technology cheaply to
`anyone who asks in order to promote wide acceptance and CCITT
`standardization.
`| > It would be really nice if Telebit could come up with a follow on to
`| >DAMQAM that was ``TRUE'' full duplex... [[see above]]
`| >support ``TRUE'' 38.4Kbps ... :-)
` V.34 Asym seemed to have died in CCITT. This was the proposal for a 28
`| Kbps PEP with a reverse 300-600 channel. Maybe in light of multicarrier
`| cellular, satellite, microwave, or fax modulation methods, it might be
`| given new life...
` Personally I hope it stays dead (no offense intended.) I would rather
`see a dynamic channel allocation scheme standardized and much rather see
`a full-duplex multi-carrier standard. If CCITT were to standardize
`around a full-duplex multi-carrier technology right now before any
`company has a product (and therefore a market advantage*) much as they
`standardized on V.32 before any product existed, I think that it would
`stimulate product development in the same way the V.32 standard did.
` * Note that Telebit is going to have a market advantage in *any*
` multi-carrier technology because of their background in the field.
`
`||
`
`||
`
`Page 6 of 19
`
`

`
` There's really nothing that can or should be done about that. They
` took the risks of developing and pushing multi-carrier technology
` before any standard existed. If multi-carrier technology turns out
` to be The Hot Tip, they deserve a jump on the rest of the pack.
` However, they don't deserve a monopoly ... (My opinion obviously.)
`Casey
`Kenneth K.F. Lui
`12/13/90
`In article <36...@cup.portal.com> c...@cup.portal.com (Cerafin E Castillo) writes:
`>I agree. I use V.32 with V.42bis compression in the receive direction
`>when using a Graphon OptimaX 200 X-Windows solution. Since the mouse
`Is there an advantage in selecting V.42bis compression in the
`receive direction rather than for both? I have data compression
`selected for both sending and receiving on my T2500 because
`V.42bis isn't supposed to expand files. Does selecting both tax
`the CPU that much more as to degrade other areas of performance?
`Ken
`______________________________________________________________________________
`tem...@ecst.csuchico.edu, tem...@walleye.ecst.csuchico.edu,|Kenneth K.F. Lui|
`tem...@sutro.sfsu.edu, tempest@wet.UUCP |________________|
`tni...@hayes.uucp
`12/14/90
`In article <35...@jaytee.East.Sun.COM>, gste...@vergil.East.Sun.COM
`(Geoff Steckel - Sun BOS Hardware) writes:
`> Open letter to Telebit: if you think PEP is worth anything, licence
`> it (with or without fee). Otherwise it will be bypassed by a (possibly
`> inferior) but widely available standard. V.32 is coming up fast.
`It's clear that most people are not aware of activities in CCITT
`Study Group XVII (the international standards committee on modems)
`and TIA TR-30 (the US national standards committee on modems)
`related to PEP. I'm an active participant in these and other
`standards organizations, and maybe I can shed some light on it.
`Telebit has been trying for at least five years to get the standards
`community to buy into multicarrier modulation, and have failed.
`There are many technical reasons: the long propagation delay
`through a multicarrier system, the half-duplex nature (echo
`cancellation capability is claimed, but has not been demonstrated
`even on paper), the complexities of supporting synchronous
`communications and async comm without buffering and flow control,
`etc. Telebit's persistence in trying to get multicarrier considered
`as the modulation standard for "V.asym" (asymmetrical modem
`standard) stalled, and eventually killed, that project. It turned
`into "V.17", an application-specific modulation technique for
`high-speed Group 3 fax, rather than the general-purpose low-cost
`high-speed modem it was intended to be.
`Now, the CCITT is working on the "V.fast" standard (full-duplex
`modulation above 14,400bps), and once again Telebit has proposed
`multicarrier. The schedule calls for test results of a full-duplex
`system to be available at the SG XVII meeting in April; the group
`can't wait any longer than that, or they won't be able to complete
`work by the end of 1992 (the scheduled completion date for V.fast).
`The Codex's, General Datacomm's, and Racal-Milgo's of the world
`won't let this project be stalled the way V.asym was stalled. I
`sincerely hope that Telebit can demonstrate multicarrier echo
`cancellation, because I'd like to see multicarrier get fair
`consideration; but I'm not optimistic.
`The problem is not that Telebit has been unwilling to license their
`patents related to multicarrier modulation, or has been keeping it
`secret. In fact, they've been quite open about how it works (in
`multitudinous contributions to TIA and CCITT) and actively trying to
`sell licenses, but have been met with a resounding yawn. A couple
`of companies licensed the technology, including Ven-Tel and
`Anderson-Jacobsen, and Intelligent Modem Corporation (Forval)
`apparently has come up with a different multicarrier scheme (and is
`
`Page 7 of 19
`
`

`
`supporting multicarrier in SG XVII for V.fast). But most modem
`companies want their products to serve a broad spectrum of
`applications, and this means providing true full-duplex modems with
`low propagation delay.
`--
`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!tni...@uunet.uu.net
`Bob Sutterfield
`12/18/90
`PPP spoofing, NetBlazer (was Re: Telebits "PEP" protocol)
`In article <87...@lll-winken.LLNL.GOV> ca...@gauss.llnl.gov (Casey Leedom) writes:
` (From what I understand, SLIP spoofing, when it becomes available,
` will actually be making up for the half duplex nature of DAMQAM.)
`VJ's header compression (RFC1144) goes a long way toward this with no
`alterations in the underlying modem. He even mentions the Telebit
`Trailblazer and USR Courier HST as examples of less-than-full-duplex
`modems that provided design goals.
`SLIP or PPP spoofing would be problematic. UUCP spoofing works
`because uucico's ACKing and retransmission is at the granularity level
`of a complete file. The "g" protocol level doesn't manage file
`retransmission or restarts in mid-file. Kermit spoofing is similar.
`But TCP streams think that, once a packet has been ACKed, it has been
`delivered to the receiving end. Retransmission and restarts happen at
`a packet granularity. If part of the circuit between transmitter and
`receiver were to accept responsibility for delivery of a packet after
`ACKing it to the transmitter, it would destroy the end-to-end nature
`of TCP.
`In article <36...@cup.portal.com> c...@cup.portal.com (Cerafin E Castillo) writes:
` SLIP spoofing, from what Telebit has told me, will never exist.
` the Telebit NetBlazer is the current SLIP/CSLIP/PPP solution
` offered by Telebit.
`These are two different issues! One decides which bits to put on the
`wire, the other is the IP circuit handling logic.
`In article <87...@lll-winken.LLNL.GOV> ca...@gauss.llnl.gov (Casey Leedom) writes:
` I'm really going to have to look at that product. I'm beginning to
` think that it might be the right thing to use for tele-commuting...
`A NetBlazer would indeed be a good thing to have in your office, on
`the receiving end of all the remote workers' dialins. It would also
`be a good thing for use between geographically-separated office sites
`that have occasional traffic, configured for on-demand connections.
`But even the base model is a little expensive for use with a single
`host, which is all most folks have at home (if LLNL employees are
`exceptions, please tell me where to send my resume :-). It's better
`for that case to implement on-demand dialup IP under that host's
`native operating system. I'd be surprised if a future KA9Q or NCSA or
`UNIX PPP implementation didn't contain that logic.
` ...On the other hand, it would still be slave to the underlaying
` modem technology...
`Exactly. The NetBlazer is just a smart router box that still needs to
`put the bits on the wire, and that's a modem's job. All the
`performance attributes of PEP or V.32/V.42/V.42bis will still be
`apparent (is that a nice way to put it? :-). Only the IP circuits
`will be easier to manage.
`Geoffrey Welsh
`12/19/90
`PPP spoofing, NetBlazer (was Re: Telebits "PEP" protocol)
`Bob Sutterfield (bob@MorningStar.Com ) wrote:
`
`Page 8 of 19
`
`

`
` >UUCP spoofing works because uucico's ACKing and retransmission
` >is at the granularity level of a complete file.
` Where did you get this little gem? UUCP-g ACKs (or request retransmission)
`of each and every packet on a real-time basis. Surely you don't believe that a
`burst of line noise could cause the retransmission of a complete newsbatch?!?
` >The "g" protocol level doesn't manage file retransmission or restarts
` >in mid-file. Kermit spoofing is similar.
` This has no bearing whatsoever on spoofing.
` >But TCP streams think that, once a packet has been ACKed, it has been
` >delivered to the receiving end. Retransmission and restarts happen
` >at a packet granularity.
` This is also true of UUCP-g.
` >If part of the circuit between transmitter and
` >receiver were to accept responsibility for delivery of a packet after
` >ACKing it to the transmitter, it would destroy the end-to-end nature
` >of TCP.
` Not if it could guarantee accurate delivery of the data to a device which
`would retransmit it to the final destination if it were to be NAKed... that is
`the way spoofing works.
`--
`UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent
`Internet: ro...@zswamp.fidonet.org | Kitchener, Ontario
`FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA
`Data: (519) 742-8939 | (519) 741-9553
`MC Hammer, n. Device used to ensure firm seating of MicroChannel boards
`Try our new Molson 'C' compiler... it specializes in 'case' statements!
`Bill Gundry
`12/19/90
`PPP spoofing, NetBlazer (was Re: Telebits "PEP" protocol)
`From article <BOB.90De...@volitans.MorningStar.Com>, by bob@MorningStar.Com (Bob
`Sutterfield):
`> In article <87...@lll-winken.LLNL.GOV> ca...@gauss.llnl.gov (Casey Leedom) writes:
`> (From what I understand, SLIP spoofing, when it becomes available,
`> I'm really going to have to look at that product. I'm beginning to
`> think that it might be the right thing to use for tele-commuting...
` A NetBlazer would indeed be a good thing to have in your office, on
`
`>>
`
`>>
`
` But even the base model is a little expensive for use with a single
`But if a user has a Sun at home, or anything that supports SLIP, they
`won't need a NetBlazer, just an expensive, for now, modem.
`Bill Gundry
`Cerafin E Castillo
`12/19/90
`Telebit Modems, NetBlazer, & IP Spoofing...
`al...@cup.portal.com writes:
`>A friend and I bought Telebit T2500 modems about three months ago. We have
`>never gotten them to work anywhere near what they are supposed to do.
`>[deleted]
`>I spent about 14 hours a day seven days a week for three weeks trying to
`>get it to work. Best results are about 4800 baud telebit to telebit.
`>[deleted]
`>Called customer service and asked if there was a bulleting board that I
`>could call to practice on. They said no, they used to have one but shut it
`>down.
`>[deleted]
`>My experience was that you read the manual and found that you have about
`>a hundred switches... Essentially, all wrong combination = failure.
`
`Page 9 of 19
`
`

`
`>I read a lot on the net, and it is apparent that if one can find the right
`>combination the machine is one of the best on the market for its purposes.
`alvin
`A Telebit modem can be a very high-priced introduction to Data Communications.
`It is most definitely not for the 'faint-of-heart'. I don't know how many
`times I have read or heard this very same story, while I was with Telebit
`and now that I am no longer there. As I have stated before, in reality there
`are only about 85 S-registers in the Telebit modem of which only 15 are
`truely needed for configuration of the modem, IN UNIX ENVIRONMENTS! For
`home PC use, the number of registers needed are considerably less. I would
`never describe any Telebit modem as "plug-and-play". I don't think the manual
`helps much either. Telebit's lack of a BBS is strange. There is no BBS
`which offers UUCP or open login; BUT there is a demonstration system which
`is based on HyperACCESS software and normally is used with the Telebit
`Demonstration System (TDS- a watered-down version of HyperACCESS...) which
`is available from Telebit (to their vendors and from their vendors to end
`users ???) for about < $50. This system normally has a T2500 G