Path: utzoo!attcan!uunet!husc6!uwvax!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <14515@mimsy.UUCP>
Date: 12 Nov 88 19:56:21 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 89

>In article <2261@looking.UUCP> brad@looking.UUCP (Brad Templeton) notes:
>>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.

In article <1248@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.)
writes:
>The problem is that the 1400/100 must REVERSE on directive reversal of
>base data.

This is true, but the point is that directional reversals need not be
(and in fact are not) frequent.

>Any protocol not "spoofed" which "waits for ACK" will
>trigger TWO FULL TURNAROUNDS PER PACKET.

Not necessarily.  UUCP's `g' protocol runs into trouble not because of
reversals---the 6-byte ack packets fit in the reverse channel---but
rather because its packet size (64 bytes * 3 = 192 bytes) is just large
enough to convince the TB+ to send a large data packet (1024 bytes) to
the other modem, but not large enough to fill the large packet.
Streaming protocols and large-packet protocols whose acks fit in the
reverse channel would run at full speed.  (Alas, IP acks sent over SLIP
do not fit, although Van Jacobson is trying to change that.  Widening
the reverse channel would also do the trick.)

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

Many of these actually have predominately unidirectional data flow.
Consider the smart editor, for instance.  I type

	edit foo

The first screen's worth of `foo' is loaded into my workstation and
displayed; more of `foo' is sent as I begin to examine the text.  (Flow
is all host->workstation.)  I decide I want to start at the end and
work backwards, and type some command.  Only about 4 kB (2 `pages') of
`foo' have reached the workstation, so the workstation sends a command
saying `preempt: send the last page'.  This message fits in the reverse
channel.  The last screenful comes over and is displayed, and then the
last 2 kB of the file flow over.  (Flow is still all host->workstation.)
As I look backward through the last 2 kB, the second-to-last 2 kB come
over.  (The theory goes that the region loaded into the workstation
should always be that that is closest to surrounding the current
location, with a slight forwards bias.)  I make a few changes.  Most
of the commands required to make those changes on the host fit in
the reverse channel.  (Never said we had to delay sending them!)  A
few do not; those require reversals.  No matter; the region I am editing
is in fact already on my workstation, and the changes are made in
parallel.  Whenever I am idle, more of the file `foo' flows over.
Only the changes I make must be sent back to the host, and most of them
fit in the reverse channel (just as what I am now typing fits in the
reverse channel on the TB+ I am using at the moment).

See the pattern?

>or any other high-density biderectional traffic you can care to think
>of, which requires a protocol.

There *are* some.  The strange thing is that, for most of us, there
are so few.

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

All the way from 300 bps to 2400 bps, we had full duplex available.
We did not make use of it not because it was not available, but
because it was either unnecessary or hard to use.  Only the latter
is likely to change.

Traffic patterns probably *will* change, but not as much as, nor as
quickly as, the pro-full-duplex crowd is suggesting.  In the meantime
we are making merry with our half-duplex patterns on our half-duplex
modems.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris