Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.dcom.modems
Subject: Re: Telebits "PEP" protocol
Message-ID: <87775@lll-winken.LLNL.GOV>
Date: 13 Dec 90 08:10:28 GMT
References: <3592@jaytee.East.Sun.COM> <87673@lll-winken.LLNL.GOV> <36853@cup.portal.com>
Sender: usenet@lll-winken.LLNL.GOV
Distribution: na
Organization: Lawrence Livermore National Laboratory
Lines: 152
Nntp-Posting-Host: gauss.llnl.gov

| From: cec@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.

| >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.
    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