Path: utzoo!attcan!uunet!seismo!esosun!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <1248@nusdhub.UUCP>
Date: 11 Nov 88 01:21:22 GMT
References: <2261@looking.UUCP>
Distribution: na
Organization: National University, San Diego
Lines: 67

in article <2261@looking.UUCP>, brad@looking.UUCP (Brad Templeton) says:
> I would rather a modem that is 1400 bytes/second one direction and 100
> bytes/second in the reverse direction than one that is 960 bytes/second
> in both directions.   (Is V.32 error free at 9600 bps, or are the error
> protocols layered on top of a 9600 bps base rate?)

The problem is that the 1400/100 must REVERSE on directive reversal of
base data.  Any protocol not "spoofed" which "waits for ACK" will
trigger TWO FULL TURNAROUNDS PER PACKET.  (what is that under PEP?  20
carriers? twice.)  The turnaround delay (with retraining?) will
introduce more of a delay than the 960/960 standing rate.

The equation is aproximately:
	( PACKETS / WINDOW SIZE) * 2 
turnarounds per transfer, with accuracy of the above increasing
proportionally to the decrease in backet size.

Mind you, this is only for non-spoofed protocols.

> I have never had an application that called for 9600 bps in both
> directions.  Many people are in the same boat.   Rather than V.32
> supplanting PEP, it might be the other way around.  People will
> eventually go to whatever is fastest.

Not so true as you might think; to whit:  (non spoofed of course)

Any small packet protocol.
Any truely intelegent workstation.
	(just picture yourself at home with a DMD/programable
		terminal preforming emacs-style functions at home.
		downloading huge files for editing while the ones
		you just finished with are being uploaded back, etc.)
Any "open-channel" bridging.
Any environment server (X-windows?  NeWS?).
Any "secure" connection.
Any real-time remote service. (remote lab monitors et. al.)

or any other high-density biderectional traffic you can care to think
of, which requires a protocol.  True, uucp and usenet, as they exist
today (and most hobbiest-level bbs up- down-load type transactions) do
not take advantage of high-density bidirectional traffic to remote
sites (simply because it didn't exist).  Having seen the future in
these areas, and knowing that someone will eventually decide that
dialup connections which move large data-groups should be made
concurent to reduce connect time.


Things like mikenet will become practical over X.25 international
links; and inter-backbone (not necessarily usenet!) transfers over
dialup lines (think insurance companies and auto clubs and ...)

I think you may be unpleasantly supprised in the not so distant
future.

> And what about PEP with echo suppression?  What could *that* do?

What??  (I may be wrong about this one, but...)  If I recall corectly
there are aproximately the same type of carrier matrx involve in both
PEP and V.32.  (both are obviously echo-supressed, and the use about
the same number of carriers.  V.32 simply has had the troublesome
turnaround whathaveyou excluded, and implements different carrier
frequencies so as to pass through international systems with less
friction.  This may be a dreadful over-simplification, but it does
apply in essence.)


Rob.