HDTenEightyP/NetNews huggingface dataset:
From: mparker@adobe.com (Mike Parker)
Subject: Re: PostScript support for Fax modems?
Organization: Adobe Systems Incorporated, Mountain View
Date: Thu, 12 Nov 1992 17:27:00 GMT

Patrick Hoepfner writes:
>
>I didn't explain myself very well.  It is case (2) that I am interested in.
> There is a number of vendors (NEC, Compaq, and Cannon) who are selling or
>will announce a device that will transmit a PostScript-fax message if the
>receiving machine is PS-fax capable, or it will switch to G3 if it isn't. 
>
>If a number of vendors are doing it, I guess that makes it a de-facto
>standard!

Um, yeah, Adobe at least would very much like to see it become a de-facto
standard.  Many customers in addition to Compaq and NEC are interested.

The short answer to your original question is not yet.  Several things
need to happen, Adobe needs to complete and release the documentation
on PS file transmission, Adobe needs to add an application interface to
our drivers so that third-party apps can call on it to generate PS for
them, and we need to do a little evangelism.  If you know of a modem
vendor that wants to be first, let me know.

>
>I thought that since PS-fax offers speed and resolution, the fax modem
>developers might want to support this.  For those with LaserJets, I saw a
>PS-fax cartridge.  It was advertised for around $230 (if memory serves) and
>you simply plug a phone line into the cartridge, and plug the cartridge
>into your LaserJet.  Then you have a PS-fax capable receiving machine.

I think that it probably is not PS-fax capable, it probably only
sends and recieves raster.  Adobe didn't build this cartridge so
if it sends and recieves PS files it must use some NSF frame that
is different from that in the Compaq and NEC and so is not compatible
with those machines.  Guess it's time for a little competitor research.

mike
From: dembrows@eniac.seas.upenn.edu (Barry Dembrowski)
Newsgroups: comp.dcom.fax
Subject: Wanted...info
Date: 13 Nov 92 14:10:26 GMT
Distribution: na
Organization: University of Pennsylvania


	I am looking for a product review on the Intel Satisfaxion Fax\Modem.
   I hear it is an excellent product, however, I would like to know if anyone
   has seen a write up on it in one of the trade magazines (Byte..etc.)
  
 	Also, if anyone has seen a comparison test done on any of the fax\
   modems could you please tell me where you saw it.  I'm getting info in
   order to purchase a fax\modem.  I have a 486 machine. I use MS Word for
   Windows.  My purchase will probably include a scanner and I would like to
   stay under $600 (with the scanner) however, I can spend more money if it is
   worth getting any special features.  

   	Any help is appreciated...


					email   dembrows@eniac.seas.upenn.edu
From: v110mhwh@ubvmsb.cc.buffalo.edu (David M Stokes)
Newsgroups: comp.dcom.fax
Subject: Zoltrix and WINFAX PRO 3.0
Date: 13 Nov 92 19:16:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41


Hello all!

Ok.. I know this is a Dead-old issue, but is it worth my time to get 3.0 when
2.0 never really worked well with my cheapo board?  IE did they make it more
back compatible for all those with less than $200 boards?  ;) Is there
a patch out there to make the 2.0 version work?  Thanks for any help.

Dave
From: eoph12@castle.ed.ac.uk (I F Gow)
Newsgroups: comp.dcom.fax
Subject: ?DosFax Test Drive
Date: 6 Nov 92 11:50:02 GMT
Organization: Edinburgh University



Any one know:

a) if there is a DosFax testdrive similar to the WinFax one,

b) where is it ?????

I've tried the WinFax Test drive which seems to work OK, but all the
programs I use run under DOS.   Before I fork out the cash for the
proper version, I'd like to be sure it would work on my system.  I've
heard a lot of funny stories about how it handles proportional fonts
under the HP emulation setup.

Thanks in advance,

regards,

Iain
Newsgroups: comp.dcom.cell-relay
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: clarifying the role of SSCOP?
Organization: Motorola Codex, Canton, Massachusetts
Date: Thu, 12 Nov 1992 16:10:30 GMT

rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:

>Fred, I think you're exaggerating the possibilities for raw cell loss due
>to transmission effects [not congestion, but see below]. Remember, this same
>ATM network has got to carry voice traffic with no AAL at all (well, AAL1
>is practically no AAL). Every cell dropped will be a 6ms gap in the conver-
>sation (12ms, if 32 Kb/s ADPCM is used).

My understanding is that most voice coding algorithms would be happy
with 1 to 2% cell loss rate, as long as it's not too bursty. For
straight PCM, all it does is make a small difference in the
signal-to-noise ratio.

If you send 1500-byte AAL frames, however, that 1% cell loss rate
translates into a 27% frame loss ratio. Selective-reject becomes barely
possible, and go-back-n is impractical for N>2.

Of course, using hop-by-hop selective-reject with a protocol that
guarantees sequencing (I assume SSCOP does, given its ancestry) means
that you might run into nasty delays at each hop.

				Peter Desnoyers
-- 
Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: theoretical support for hop-by-hop, not!
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 12 Nov 1992 09:37:28 GMT

craig@sics.se (Craig Partridge) writes:
+---------------
| <cell@mythos.ucs.indiana.edu> writes:
| > that, in a network with a high bandwidth-delay product, TCP exhibits
| > very large oscillations in end-to-end delay, and takes about 100
| > round trip times (losing about 190 packets) before a link becomes
| > fully utilized...
|  
|     I'd just like to note that the jury is still out on these results.
| In general, the literature (both theory, simulation and practice) shows 
| end-to-end flow control outperforming hop-by-hop.  And I've heard folks
| question whether the representation of TCP-IP in the model was accurate.
+---------------

The oscillation is real, and quite large; I have seen it during FTPs with
"hash" turned on. But also note that Jon Crowcroft (et al?) published a paper
some time ago which proposed a simple change to TCP slow-start that smooths
out most of the oscillation. I wouldn't count TCP (or end-to-end congestion
control) out yet...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Flow Control
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 12 Nov 92 20:58:20 GMT

Bursty Data Flow Control Issue:

The near term flow control problem can be limited to solving the 
bursty data problem in the local area environment where we need to 
duplicate the current services offered by FDDI and switched ethernet.  

Currently there is no mechanism, short of using routers, which
allows bursty traffic across wide area networks.  So in the WAN case
the net can require circuit building procedures with implied bandwidth
reservation and rate based data release, or require the use of embedded 
routers.

Ron suggested a "backpressure" (did Tyment invent this term?) method
which can be used in a local multi-hop environment.

Ron's method does duplicate the implicit congestion control which
distributed LANs currently employ in the sense that bursty traffic ties 
up all source destination pairs though some pairs may be disjoint from 
the original offending pair.

Ron's method has not solved the WAN feedback issue, namely that the
host may have released the entire burst load before receiving the RBCE 
bit.  However in a local environment when links are short and hops few, 
the feedback delay is small enough to that the RBCE should migrate back

The method could be applied independently in local regions so that a RBCE  
does not back down a wide area link into another local region which didn't 
causing the original problem.

Thus I am opinioning:

  * Accept a hop by hop feedback mechanism for the local environment,
    dis-allowing its usage across multiple domains. Thus duplicating  
    existing  LAN service.

  * Use embedded routers to duplicate existing service over WANs.

  * Newer services such as voice or video applications, distributed 
    database, transaction routing, high speed channel to channel transfer
    must use the new bandwidth reservation mechanisms and call set up.
From: jta@foo.ans.net (John Amenyo)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Hop-by-hop flow control (was: Re: clarifying the role of SSCOP?)
Date: 12 Nov 92 23:16:57 GMT
Organization: Advanced Network and Services

I  think  the other readers of this list will also find the following message useful.
Earlier, I sent a copy to Rob Warnock.


Hello,

I read with great interest your posting, "Hop-by-hop flow control
(was: Re:clarifying the role of SSCOP?)" to the comp.dcom.cell-relay
mailing list on Nov. 12, 1992.

The hop-by-hop alternative to credit systems that you proposed
(traffic class distinctions, separate buffers for traffic classes, "reverse
bursty congestion experienced" backward indication) is remarkably
similar to the ATS concept and its ramifications that has been propounded
by Prof. Aurel A. Lazar and his group at  the Center for Telecommunications
Research (CTR) at Columbia University in New York City.

ATS stands for Asychronous Time Sharing and is a variant of ATM. 
The aspects of ATS dealing with joint scheduling and admission control have
been published recently by J. Hyman and A.A. Lazar in the 1992 Proceedings
of the ACM SIGCOMM Conference. Other work has been done in the areas
of integrated reference model, knowledge-based monitoring, single 
node/switch scheduling and distributed scheduling. For example, beyond
using overload watermarks to initiate backward congestion indication,
one could take advantage of the highly correlated nature of broadband
traffic to do traffic prediction and send congestion indications well in
advance of the actual congestion conditions. (See, for example,
J.T. Amenyo, A.A. Lazar and G. Pacifici's paper in the Proceedings of the
IEEE INFOCOM 1992 Conference.)

If you are interested in learning more about results in the above areas, I 
suggest you contact Prof. A.A. Lazar or Dr. Giovanni Pacifici at CTR.
I believe several of the documents are still online for you to access by 
anon. ftp.

Cheers.

                                                               jtA
Newsgroups: comp.dcom.cell-relay
From: "Allen Robel" <cell@mythos.ucs.indiana.edu>
Subject: Re:  new AAL (SSCOP?)
Organization: Indiana University
Date: Mon, 9 Nov 1992 03:19:44 GMT

atkinson@itd.nrl.navy.mil writes:

>This is a strong statement.  It is not at all clear to me that a Van
>Jacobson TCP will not be sufficiently effective.  I'd be much obliged
>if you'd explain why you believe there is a problem with handling
>things with TCP/IP/AAL5 without the other mechanism you mention.

Ran,

Partho Mishra and Hemant Kanakia give fairly convincing evidence 
that TCP is not all that effective at efficient flow control 
over multihop high-speed networks in their paper "A Hop by Hop 
Rate-based Congestion Control Scheme" that appeared in Computer 
Communication Review SIGCOMM '92 Proceedings in which they compared 
their hop by hop (HBH) scheme of flow control to TCP as implemented in 
4.3-Tahoe BSD (they also compare HBH with the modified window adjustment 
in the 4.3 BSD Reno version of TCP).  Their results seem to indicate 
that, in a network with a high bandwidth-delay product, TCP exhibits
very large oscillations in end-to-end delay, and takes about 100
round trip times (losing about 190 packets) before a link becomes
fully utilized.  In contrast, HBH loses NO packets and maintains
a very even end-to-end delay variance.  Note that I'm not condoning
their scheme.  I'm just saying that there are schemes out there that
do better in the area of flow control than current implementations of 
TCP in high speed networks.

regards,

allen
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: ATM "style"
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 11 Nov 92 15:33:18 GMT

In article <1992Nov11.081335.645@unet.net.com>, earlf@trappist.net.com (Earl Ferguson Adv Dev) writes:

> Larry Roberts
>and NetExpress have proposed a very efficient method for establishing
>momentary VCI/VPI paths for short communications which will take only 
>a fraction of the time to completely transmit as the current proposed
>call establishment based on Q.93B.

Can we get more information on this please?
From: johng@oce.orst.edu (John A. Gregor)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Sizes
Date: 5 Nov 92 20:14:53 GMT
Organization: Oregon State University, College of Oceanography

In article <Bx56uF.4EK@ux1.cso.uiuc.edu> gardner@ux1.cso.uiuc.edu (Mike Gardner) writes:
> Network connection speeds have not increased anywhere near the
> increases in desktop performance.

Tell me about it.  I notice it every time I accidently meander onto an
NFS mounted partition.  When I do things, it's usually to 10's or 100's of
MB.  Ethernet is very noticeable.  It's usually faster to log onto the
machine that owns the disk.

> One of the reasons is that you can simply do things faster and more
> efficiently locally.  

Ummm, not with 30GB spread between 10 machines.  True, this isn't
typical, but I'm not alone either.

> MOST desktop machines don't use near the capacity of their ethernet
> connection.  

MOST machines spend MOST of their time running AfterDark(tm).  It's the
performance in the crunch that matters, whether you need it 16 hrs./day
or once every 3 months.  Build for the peak load.

> and what could they possible do with it.  Watch the soaps is my only
> answer.....

How about:
    -File mirroring/migration
    -Process migration
    -Speculative execution
    -Distributed memory
    -Distributed processing
    -Remote graphics
    -Adaptive load balancing
    -...
    -The soaps, American Gladiators, etc. :-)

My guess is that the next generation's network traffic will
    -Be very bursty in nature
    -Need small latencies
    -Need very high bandwidth
    -Be system initiated (i.e. 'housekeeping' work for the system's
     benefit, never directly seen by the users)

> Ethernet will be around when I retire.
So will Bisynch, DecNet, Cobol, etc.  Just a matter of how hard you
look.

-JohnG
-- 
         John A. Gregor			USmail:	College of Oceanography
 E-mail: johng@oce.orst.edu			Oregon State University
Voice #: +1 503 737-3022			Oceanography Admin Bldg. #104
  Fax #: +1 503 737-2064			Corvallis, OR  97331-5503
Newsgroups: comp.dcom.cell-relay
From: jh@etana.funet.fi (Juha Heinanen)
Subject: Re: new AAL (SSCOP?)
Organization: Finnish University and Research Network
Date: Tue, 10 Nov 1992 18:22:27 GMT

In article <9211092138.AA00486@circinus.bellcore.com> smq@circinus.bellcore.com (Scott M. Quinn) writes:

   Does this observation apply to just user-user traffic, or does it 
   also apply to signalling traffic? 

Fine with me if the signalling folks decide that SSCOP is ok for them,
but at least SSCOP should then be renamed as Signalling Specific
Connection Oriented Protocol.  I haven't found much support in using
it below any other connection oriented protocol.  For example, if
someone wants to implement X.25 over ATM, a better choise is to map
LAP B (or whatever the link layer standard for X.25 is) right over
ALL5 rather than trying to do X.25 over a new thing, ie. SSCOP.

-- Juha
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
-- 
Newsgroups: comp.dcom.cell-relay
From: nagle@netcom.com (John Nagle)
Subject: Re: The Low Cost Backbone
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 10 Nov 1992 17:53:45 GMT

myoung@force.ssd.lmsc.lockheed.com writes:
>More on the Lockheed switch, making it ATM comaptible:

>The probability of buffer overflow is replaced by the probability that
>an out of sequence cell is still circulating in the backbone when
>its neighbors are forwarded to the access node.

       Cute.  The transmission medium (fibre, etc.) IS the buffer.
It's like a railroad with no yards, just switches, and the trains
never stop until they reach their final destination.

       If nodes are too close together, does this create problems?

					John Nagle

       
Newsgroups: comp.dcom.cell-relay
From: jh@etana.funet.fi (Juha Heinanen)
Subject: Re: new AAL (SSCOP?)
Organization: Finnish University and Research Network
Date: Mon, 9 Nov 1992 19:37:25 GMT

fred,

can you tell me why SSCOP can't be enhanced to a real transport
protocol if it is already close to an ISO high-speed transport
proposal?  coudn't that be done my simply adding multiplexing
capability to the current SSCOP proposal?

-- juha
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
-- 
Newsgroups: comp.dcom.cell-relay
From: jh@etana.funet.fi (Juha Heinanen)
Subject: Re: new AAL (SSCOP?)
Organization: Finnish University and Research Network
Date: Thu, 12 Nov 1992 17:35:19 GMT

In article <1992Nov11.045929.18654@nntpd.lkg.dec.com>
goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:

   At risk of seeming even more impetuous than usual (it's midnight),
   what are they drinking over there in Yurop?  LAP-B over AAL5?

Fred,

The suggestion to do X.25/LAPB/AAL5 is not from Europe, but from KDD
in Japan.  The point is that the other end of the X.25 connection will
not be in B-ISDN, but in the "old" world.  Then it is important to
preserve compatibility also at the link layer.  I don't see any point
is running X.25 end-to-end over ATM.  So the performance that we need
out of the X.25 over ATM need not be be more we get from X.25 over old
stuff, but compatibility becomes the key issue.

   Just as the TCP/IP fanatics are religious about TCP doing it all,
   I sometimes suspect many PTT types of believing that X.25 was
   dictated at the Sermon On the Mount.

I don't like fanatism either and don't belong to those that would like
to use TCP for ever over everything.  The only point I have tried to
make is why can't you make SSCOP a real transport protocol, since you
are already saying that it does almost the same as TCP.  

What it doesn't have is multiplexing (addressing) capability.  If you
would add that, then you and I could use the SAME protocol for Q.93B
(with null address fields) and for real end-to-end transport purpose
(with address fields).  So I'm against SSCOP only because of this
omission.

-- juha
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
-- 
Newsgroups: comp.dcom.cell-relay
From: jh@etana.funet.fi (Juha Heinanen)
Subject: Re: SMDS Again
Organization: Finnish University and Research Network
Date: Mon, 9 Nov 1992 19:23:12 GMT

E.164 addresses are subnetwork dependent ones and owned by CCITT.  IP
addresses, on the other hand, are network layer addresses.  neither of
them are suitable for ATM internets consisting of any number of
arbitralily connected public and private networks.  IP would otherwise
be ok, but it is running out of its address space.  a better
alternative is to use NSAPs as ATM end point identifiers no matter
what protocol one is running once theATM connection is established.
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
-- 
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: The Low Cost Backbone
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 10 Nov 92 20:56:38 GMT

In article <1992Nov10.175345.24248@netcom.com>, nagle@netcom.com (John Nagle) writes:
>
>       Cute.  The transmission medium (fibre, etc.) IS the buffer.
>It's like a railroad with no yards, just switches, and the trains
>never stop until they reach their final destination.
>
>       If nodes are too close together, does this create problems?

The system likes very high speed (200 Mbps and up), low cost fiber in a 
campus environment.  The idea is that fiber drops in price faster than 
high speed memory, so its cheaper to just add more fiber as bandwidth needs
increase, the switch itself is not the costly item.  Now all the LAN hubs
connect to the mesh of fiber providing speed of light transfer.
Newsgroups: comp.dcom.cell-relay
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re:  new AAL (SSCOP?)
Organization: Digital Equipment Corp., Littleton MA USA
Date: Tue, 10 Nov 1992 23:20:09 GMT


In article <1992Nov9.135828.5489@iscnvx.lmsc.lockheed.com>, myoung@force.ssd.lmsc.lockheed.com writes...
>In article <1992Nov8.231642.7509@nntpd.lkg.dec.com>, goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
>>Just in case anyone's wondering, SSCOP (service-specific 
>>connection-oriented protocol) is the service-specific sublayer that sits 
>>above AAL3/4 OR  AAL 5.
>  There are lots of connection oriented protocols.  What makes this one
>so special.  If its value added is a rate oriented flow control, then
>why not fix TCP, or use VTMP or XTP or any of a number of other
>proposals.  What makes SSCOP the preferred protocol?

SSCOP doesn't have rate-oriented flow control.

SSCOP is a general-purpose sublayer that provides elements of 
procedure for recovering lost packets.  That is, it does what other
connection-oriented DATA LINK procedures, like LAPF, do, and what
connection-oriented TRANSPORT procedures, like TCP, do.  It differs
in that there can be many separate gaps being recovered at once.

The SSCOP STAT message includes a list of gaps in the received
sequence.  So you may have received everything up to 8831, missed
8832-8834, gotten 8835-8901, missed 8902, gotten 8903-8908, missed
8909, gotten 8910-8955, and that's the latest you've heard.  TCP
has no way to say all that at once, so it can't recover them all
at once, all the while sending up to the credit limit. 

There is a project in X3S3 (CSRDLC) to do the same thing with HDLC,
and the two groups are in contact.  The syntax may end up different
but the semantics are likely to end up very close.  Interoperable?
Maybe.

It always amazes me how IP fanatix think that the entire Internet 
Protocol Suite as of the late 1980s was handed down on Sinai.
---
Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.
Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Big Cell App
Organization: Basket Weavers, Inc.
Date: Thu, 5 Nov 1992 06:48:20 GMT

In article <1992Nov3.164731.12244@iscnvx.lmsc.lockheed.com> myoung@force.ssd.lmsc.lockheed.com writes:
>I was asked about a potential application which prefers larger
>cell sizes.  OK, let me try to invent one.

	[....]

As an aside - I've seen many invented scenarios and questions posed
by you in this newsgroup over the last few months. Could you summaries
your own answers to your questions, or the answers others have given?

gja
Newsgroups: comp.dcom.cell-relay