HDTenEightyP/NetNews huggingface dataset:
From: staffan@nynashamn.telesoft.se (Staffan K-E Ungsgard)
Newsgroups: comp.dcom.fax
Subject: Re: Winfax bugs - what to replace it with
Date: 13 Oct 92 16:10:01 GMT
Organization: Telesoft Norden AB

rick@digibd.com (Rick Richardson) writes:
: jpp@StarConn.com (John Pettitt) writes:
: 
: >Winfax seems to have a protocol bug when talking to some brands of fax
: >machine that causes transmission to stop after the header page.    This
: >is destination dependent (i.e. all faxes to the offending destination
: >fail and the failing faxes can be sent to other destinations with no
: >problem).   As has been noted before tech support for WinFax is
: >non-existant so I am looking for suggestions for a good fax package to
: >replace it with.  Hardware is a Dell 3/20 notebook with a Dell fax
: >modem, running dos 5 & windows 3.1.
: 
: I'm not famililar with the Dell fax modem, and I've only toyed with
: DOS fax packages (or DOS itself for that matter), but if the Dell
: fax modem is an ersatz Class 2 type of modem, the problem is more
: likely with the modem itself, rather than WinFax.
: 
  -- Stuff deleted --
: 
: I guess my advice would be to try a different brand of modem with
: WinFax, before giving up on it.
: 

I've had the exact same experience with both a Wellcon modem and a Supra.
Both are v42Bis modems. Both fails most of the times when connected to 
one of the faxmachines at work (Swedish Telecom model 530), but works just
fine to my fathers fax (a Panasonic Panafax). Both fax machines work fine
when it comes to sending and transmitting to other faxmachines. So what John
Pettitt suggests above is in line with what I have seen too.

Staffan Ungsgard
Telesoft Noreden AB
NYNASHAMN, SWEDEN
From: yow!yow (Raymond Yow)
Newsgroups: comp.dcom.fax
Subject: HELP !!!
Keywords: fax
Date: Tue, 13 Oct 92 21:49:34 PDT
Distribution: world
Organization: VAR provides turnkey system to corporate account
From: yow!yow (Raymond Yow)
Newsgroups: comp.dcom.fax
Subject: 200 to 300 DPI conversion problem
Keywords: problem
Date: Tue, 13 Oct 92 23:59:33 PDT
Distribution: world
Organization: VAR provides turnkey system to corporate account

Hi, all the fax techies out there, I am having this real big problem
with my fax/modem card. Well, let me explain it...

   We have a MicroFax fax card installed in one of the PC to receive
incoming fax. the card is class 1 and 2 compatible. We write some
commercial applicatons that will enable us to fax encrypted message
in a 2-dimensional bar-code form to another fax. If the other site
has a fax machine, everything is okay, they can scan in the bar 
code to decrypt the message. but if they use commercial fax software
like Gammalink or WinFax Pro with their fax card and 300 DPI printer,
the bar-code get out of alignment and is not readable by the laser
bar code reader anymore. It seems to me that the problem is on the
DPI conversion. The fax uses 200 DPI as standard tranmission while
most printers print at 300 DPI. Somehow when the software do the 
conversion to 300 DPI, the fax gets mess up.(FYI, our bar-code is 
very sensitive to the change in the distance between black dots and
also the width of the dots. After the fax get printed on the 300 DPI
printer, The size of the bar-code gets smaller and off-alignment). 
Is anyone one out there know of this problem and if you do, please 
shine a light on me, it is driving my boss up the wall.

P.S. We use a DOS and Windows 3.1 base fax software.

Also, here are a few more questions...
1. Could anyone tell me where to get the standard for fax. Isn't 
   there something like T.30 ? 
2. How exactly is the DPI conversion works, is there some algorithm 
   that they use ? 
3. We are looking for a fax card manufacturer that have a WINDOWS 3.1
   API (good one) so that we can integrate fax feature into our WIN 3.1
   application. Do you know of any good one ? I have talk to GammaLink
   and they seem to be one of the powerhouse. Am I right?



Thanks in advance..

Raymond---    

Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.cell-relay
Subject: Re: VCI/VPI usage
Date: 15 Oct 92 12:06:07 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

myoung@force.ssd.lmsc.lockheed.com writes:
+---------------
| Work Group Connectivity:
|   How many VCI/VPI pairs does it take to connect up the workgroup?
| If 256 desktops need permanent connections to each other, then 
| using directed graphs reduces the required VCI/VPI to 256. ...
|   What's missing from this picture?
+---------------

What's missing is that most ATM switches being designed so far do *not*
have output queues big enough to allow each of your 256 PVCs to support
"bursty" traffic. So instead of having the desired (say) 155 Mb/s pipe
from each workstation to "the world", each station will have 256 connections
opened with reserved bandwidths of 0.6 Mb/s or less. For typical workstaion
user loads, this is far *worse* than everyone sharing a single Ethernet!

No, I suspect that in most LAN environments each workstation will have a
single PVC open with a "medium" reserved bandwidth (say, 1 to 10 Mb/s) to
a bridge/router to handle ARP/DNS/NIS/YP/etc. traffic, Telnet, FTP control
channel, and the like. Then it will open a higher-speed VC (10-100 Mb/s) on
demand for just the duration of the need, e.g., an FTP data channel iff the
file is bigger than some configurable size, a video channel for the duration
of the conference call, etc.

For the above analysis to be wrong -- and I devoutly *hope* it is, but
doubt it -- the ATM switches sold in LAN environments would have to have
output queues sized like true bridges/routers at the access-link speed,
that is, some small number of megabytes of buffer per output port. Otherwise,
the ATM switch is simply not going to be able to handle several of its
attached workstations suddenly sending full link-speed bursts of cells
at some single other workstation -- a *very* common occurrence in a
client/server environment!

But what I've been hearing (and again, I could be wrong) is that ATM switches
are being designed *depending* on the fact that bandwidths are allocated at
call-setup time, and thus SINCE NOBODY WILL EXCEED THEIR ALLOCATED BANDWIDTHS,
the output queues can be rather small, some 100's to small 1000's of cells
per port. Well, 1000 cells -- 48 KB of payload --  is *far* too small for
the ATM switch to act as a generic "reflector" for bursty traffic. You need
more like 10,000 to 50,000 cells/port.

For example, we already see that Ethernet bridges with only 64 KB of output
queue per port become congested and start dropping packets with only a few
high-performance workstations beating on them. [Hint: Our current TCP defaults
to 60 KB receive windows. Gues what happens when a few "rcp" start up.] Even
at only 10 Mb/s, output queues of 500 KB/port (or larger) are mandatory, and
as speeds go up, "a few" MB/port (~50 Kcell) will be needed.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: ATM over T1; use of header address bytes
Date: 7 Oct 92 16:27:14 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <1992Oct7.004409.28768@qualcomm.com> brobbins@qualcomm.com (Barry Robbins) writes:
>>From what I've read and my conversations with vendors, it would seem that
>ATM interface rates officially start at 155Mbps (OC3), with 45Mbps (T3) 
>the lowest rate any switch will support. 
>
>My first question:
>Is it possible, in a private network using leased T1s and an ATM switch, to 
>support ATM cells over T1 interfaces?  Is anybody out there doing this?  Do 
>any switch vendors support this?   How would one pack the cells into the
>T1 frame, just skip every 193rd framing bit?  How are cells delineated on a
>synchronous interface in general.
>

SMDS (which is ATM and is essentially BISDN) is defined for use over
T1 speeds. The RBOC's are doing this. Cells are packed asynchronously
(they have no relation ot the framing of the T1). Cells are identified by
validating the CRC checksum in their header.








-- 
i.sinature
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Burstiness and Peak bit rate info. wanted
Date: 9 Oct 92 08:13:03 GMT



there is a paper we have at networks 92 at trivandrum this motnh on
characteristics of multimedia traffic 

onm
cs.ucl.ac.uk:

in
darpa/janetvid.ps 
(postscript)

it is mainly real measurements

then, how to seet the QoS? well, that is easy for phase 1, just set
the peak cell rate -

later, when you can set mean, peak, burst (or leaky bucket size, or
cell delay variance) it
gets more interesting

 jon
From: dm@cl.cam.ac.uk (Derek McAuley)
Newsgroups: comp.dcom.cell-relay
Subject: Re: ATM over T1; use of header address bytes
Date: 7 Oct 92 16:08:47 GMT
Reply-To: dm@cl.cam.ac.uk (Derek McAuley)
Organization: U of Cambridge, England

rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
> brobbins@qualcomm.com (Barry Robbins) writes:
> +---------------
> | How are [VPI & VCI] used?  How do they differ?
> +---------------
> 
> The VPI is primarily for internal long-haul telco use, at the higher levels
> of their switching hierarchy.

It also allows virtual private networks; the provider switches only on VPI and
the VCI field is left at the user/network interface to be used in any way the
user sees fit. New VCs can be established between sites interconnected by
virtual path service without necessarily resorting to any signalling to
the carriers network.

I too agree that the division is a logical concept and defining it by
saying 8 /
16 bits VPI / VCI at the UNI for BISDN is an irrelevance. The other issue of
course is that if the network gets big do we need more than 24 bits for the
circuits in the middle; will CCITT in 2000 be defining a Backbone Backbone
Interface (BBI) with extra bits for {\em virtual spine indentifiers}?

Mac.
Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: VCI/VPI usage
Organization: Basket Weavers, Inc.
Date: Thu, 8 Oct 1992 07:41:25 GMT

In article <1992Oct7.135314.8217@iscnvx.lmsc.lockheed.com> myoung@force.ssd.lmsc.lockheed.com writes:

>Work Group Connectivity:
	[..]
>  What's missing from this picture?

Without meaning to be impolite, but I find many of your postings to be
missing (to my mind, at least) a clear connection between the applications
you postulate and the cell level technology of fibres, cell switches,
ATM interfaces and AALs. You seem to vaguely drift and connect layer 1-ish
concepts (like VCI/VPIs) with layer 4-and-up-ish issues (like creating
distributed computing networks, hotel reservation systems, etc). I'm
not convinced that ATM technology aims, or claims, to provide the sort of
intelligence or protocols you seem to expect it to.

Or perhaps I'm just missing something?

>Comment:
>
>  Can we please change the term VCI/VPI pair to something easier,
>like "path identifier".

I would suggest you don't. In the context of ATM style cell-relay
the VCI/VPI pair has a well established meaning. It is a path identifier
only in the context of a given inter-cell-switch fibre (strictly)
although a fixed VPI (and within that, VCI) might sometimes be
established to identify a path across multiple switches. Unless you
are precise about the "layer" of your "path identifier", and its context,
you could be in for much confusion (generation).

gja - who's possibly a bit wrong himself.
From: art@acc.com (Art Berggreen)
Newsgroups: comp.dcom.cell-relay
Subject: Re: ATM over T1; use of header address bytes
Date: 7 Oct 92 16:03:15 GMT
Article-I.D.: acc.1992Oct7.160315.21580
Organization: ACC, Advanced Computer Communications

In article <1992Oct7.135029.8089@iscnvx.lmsc.lockheed.com> myoung@force.ssd.lmsc.lockheed.com writes:
>In article <1992Oct7.004409.28768@qualcomm.com>, brobbins@qualcomm.com (Barry Robbins) writes:
>>>From what I've read and my conversations with vendors, it would seem that
>>ATM interface rates officially start at 155Mbps (OC3), with 45Mbps (T3) 
>>the lowest rate any switch will support. 
>>
>>My first question:
>>Is it possible, in a private network using leased T1s and an ATM switch, to 
>>support ATM cells over T1 interfaces?  Is anybody out there doing this?  Do 
>>any switch vendors support this?   How would one pack the cells into the
>>T1 frame, just skip every 193rd framing bit?  How are cells delineated on a
>>synchronous interface in general.
>>
>  Starting out with a very naive response, why can't the T-1 line be used
>as a simple byte stream, leaving the issue of the T-1 frame to the lower
>level.  Since the T-1 cells are fixed in length, then cell relay framing 
>byte would synchronize the receiver.  How does SMDS do this?

SMDS synchronizes the ATM cells with T1 ESF "superframes".  The ESF superframe
contains 576 octets, several of which are used by SMDS for framing and other
overhead.  The remaining octets are used to carry 10 ATM cells within
every ESF superframe.  This works out to about 92% line efficiency.

Art
Newsgroups: comp.dcom.cell-relay
From: rolf@kentrox.uucp (Rolf Hahn)
Subject: Re: ATM over T1; use of header address bytes
Organization: ADC Kentrox, Portland OR
Date: Fri, 9 Oct 1992 21:48:06 GMT

>
>SMDS (which is ATM and is essentially BISDN) is defined for use over
>T1 speeds. The RBOC's are doing this. Cells are packed asynchronously
>(they have no relation ot the framing of the T1). Cells are identified by
>validating the CRC checksum in their header.
>
>
Wrong.  SMDS L2_PDUs are placed within a PLCP layer (Physical Layer convergence
Proceedure). The PLCP layer has its own framing octets and error calulation by
bit interleaved parity.  The T1 ESF frame boundary defines the PLCP octet boundary.
There is real no CRC in the L2 header.  There is only a fixed bit sequence that works
for a CRC.  For DS3 the frame pulse defines nibble boundarys for the DS3 PLCP. 
I think ATM cells will also be placed within a PLCP layer.
From: ecc+@ERNST.MACH.CS.CMU.EDU (Eric Cooper)
Newsgroups: comp.dcom.cell-relay
Subject: ATM jobs on misc.jobs.offered
Date: 15 Oct 92 20:19:33 GMT
Article-I.D.: cs.Bw6J4p.Cw4.1
Organization: School of Computer Science, Carnegie Mellon
Originator: ecc@ERNST.MACH.CS.CMU.EDU

Fore Systems has posted a number of ATM LAN job openings on misc.jobs.offered.

			Eric Cooper

Fore Systems, Inc.	 Phone: 412 967 4040
1000 Gamma Drive           FAX: 412 967 4044
Pittsburgh, PA  15238   E-mail: ecc@fore.com
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: VCI/VPI usage
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 7 Oct 92 13:53:14 GMT

Work Group Connectivity:

  How many VCI/VPI pairs does it take to connect up the workgroup?
If 256 desktops need permanent connections to each other, then 
using directed graphs reduces the required VCI/VPI to 256.  Each
desktop would build a directed graph out to the other 256, including
itself.  Thus a distributed application within the workgroup can
use a well known handle to send a message to any other, just like
the current addressing schemes, except that some mechanism would have
to be defined to identify the source of each message.

  In many cases, a complicated transaction scheme may involve many
workstations over the entire enterprise, in these cases, the 
application can build a temporary directed graph to collect the
result of some distributed access, then closing down the directed
graph after completion.

  What's missing from this picture?

Comment:

  Can we please change the term VCI/VPI pair to something easier,
like "path identifier".
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Bridging;Segmentation
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 13 Oct 92 16:11:31 GMT

Segmentation and Bridging:

As I look over the fddi and cisco newsgroups the most commonly discussed
issue is 1) Segmentation and 2) Bridging vs routing.  Seems that cell
relay eliminates much of the discussion.

Segmentation:

  A complete message undergoes a segmentation process into cells
at the source, and regardless of the media through which it travels,
no re-segmentation need take place.  (Except in that unusual case when
two networks use different cell sizes.)  

Bridging:

  The virtual path can be view either as a bridging technology or
a routing technology.  (Related to the concept of a level 2 or level 
3 call set up). If standard IP routing is required, the cell
relay network simply "bridges" the message to the nearest imbedded
router.
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: (none)
Date: 9 Oct 92 11:59:25 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <BvtDKp.CLF@usenet.ucs.indiana.edu> KUMQUAT@SMCVAX.BITNET writes:
>Received: from SMCVAX.BITNET (KUMQUAT) by MITVMA.MIT.EDU (Mailer R2.08 R208004)
> with BSMTP id 1305; Thu, 08 Oct 92 09:06:23 EDT
>Date: Thu, 8 Oct 92 09:04 EDT
>From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT@SMCVAX.BITNET>
>Subject: SMDS vs. ATM vs. B-ISDN
>To: comp.dcom.cell-relay@ucs.indiana.edu
>X-VMS-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"
>
>
>>SMDS (which is ATM and is essentially BISDN) ...
>
>>i.sinature
>
>I really do hate harp on syntax, semantics, terminology, etc., but I must
>disagree with this statement.  SMDS is not ATM nor is it essentially B-ISDN.
>
>SMDS is a service description from Bellcore, currently defined to run
>over a DQDB (IEEE 802.6) transport.  DQDB *is* indeed a form of cell relay,
>but it is not ATM.  Yes, DQDB/SMDS cells have a similar format as AAL3/4 cells,
>but that still doesn't make DQDB equivalent to ATM nor AAL3/4.  To
>understand IEEE 802.6 operation and SMDS protocols and procedures yields
>no understanding of ATM procedures and vice versa.
>

I don't mean to preach about this but the concept of ATM has been around
for at least 12 years. It is a service concept which includes as a 
particular subinstance B-ISDN.

ATM is Asybchronous Transfer Mode which is a way of conveying infromation.
It is certainly not limited to some AAL spec inside of BISDN.

I hate to preach about this but if we are ever to prgress we must
find ideas not implementations of specs.

>Similarly, B-ISDN is a service definition.  At best, SMDS is a subset of
>B-ISDN but in its current incarnation, SMDS will not be able to support all
>of the B-ISDN multimedia services.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

-- 
i.sinature
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Call Setup Revisited
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 16 Oct 92 17:16:59 GMT

Mechanism for Call Set Up:

Call set up for cell relay workgroups is going to remain
a controversy.  

- If the design requires that a connection be made and kept open 
for the duration of the application, then the bandwidth is reserved 
for long periods when the application is idle, because data is not 
just bursty, but intermittent.

- If the design requires that the application know what kind of
bandwidth it requires, then the existing applications (NFS, Telnet)
must be modified at a level higher than the data link.

- If the design requires that a connection be opened for each message, 
then closed until the next message then additional control traffic
results, and for existing terminal emulations (Telnet) the solution
is not satisfactory.

Routers can be made to cooperate, or be replaced, the issue is
acute mainly for local workgroup applications.  

What if the design allowed each desktop to keep open a well know PVC 
for continual activity.  Then the problem becomes one of adding sufficient
buffer capacity for the cases when multiple desktop access a single
destination simultaneously. On the switch, the problem of providing buffer 
capacity using low cost dynamic rams for 155 Mbps links becomes difficult,
however for 10-40 Mbps links, dynamics ram buffers are much easily 
designed.  Allowing a station to use a well known PVC for local activity
offers the simplest method of backward compatability.
Matt Young
Lockheed
(408) 756-6789
Newsgroups: comp.dcom.cell-relay
From: KUMQUAT@SMCVAX.BITNET
Subject: (none)
Organization: Indiana University
Date: Thu, 8 Oct 1992 17:50:26 GMT

Received: from SMCVAX.BITNET (KUMQUAT) by MITVMA.MIT.EDU (Mailer R2.08 R208004)
 with BSMTP id 1305; Thu, 08 Oct 92 09:06:23 EDT
Date: Thu, 8 Oct 92 09:04 EDT
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT@SMCVAX.BITNET>
Subject: SMDS vs. ATM vs. B-ISDN
To: comp.dcom.cell-relay@ucs.indiana.edu
X-VMS-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"


>SMDS (which is ATM and is essentially BISDN) ...

>i.sinature

I really do hate harp on syntax, semantics, terminology, etc., but I must
disagree with this statement.  SMDS is not ATM nor is it essentially B-ISDN.

SMDS is a service description from Bellcore, currently defined to run
over a DQDB (IEEE 802.6) transport.  DQDB *is* indeed a form of cell relay,
but it is not ATM.  Yes, DQDB/SMDS cells have a similar format as AAL3/4 cells,
but that still doesn't make DQDB equivalent to ATM nor AAL3/4.  To
understand IEEE 802.6 operation and SMDS protocols and procedures yields
no understanding of ATM procedures and vice versa.

Similarly, B-ISDN is a service definition.  At best, SMDS is a subset of
B-ISDN but in its current incarnation, SMDS will not be able to support all
of the B-ISDN multimedia services.

I don't mean to preach about this...

Gary Kessler
MAN Technology Corp.
802-879-3375
kumquat@smcvax.bitnet
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: ATM+SONET point-to-point
Date: 15 Oct 92 20:59:39 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute


Hi,
	I've been asked to look into the issue of designing an OC-12
(??) 622 Mb/s interface/gateway for our ATOMIC LAN.  We have a LAN
point-to-point channel speed of approximately 640 Mb/s, so this is a
reasonably clean match.  I can use single channels in our base
technology as output/input feeder channels.

	I need some pointers to relevant documents that discuss the
standards that I need to use, SONET/ATM, and pointers to SONET parts
suppliers.  I have been led to believe that this would be a dark fiber
application initially, so I do not need to worry about call set-up and
so on yet.

Thanks in advance,
		--- ggf
--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
From: duke@valentine.ics.uci.edu (Duke P. Hong)
Subject: Re: Burstiness  and Peak bit rate info. wanted
Newsgroups: comp.dcom.cell-relay
Reply-To: duke@ics.uci.edu (Duke P. Hong)
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.
Date: 8 Oct 92 22:39:34 GMT

In article <1992Oct8.160252.20750@tamsun.tamu.edu> amitava@cs.tamu.edu (Amitava Raha) writes:
>
>I would appreciate it if anyone could give some information/ref  as to how
>the peakbit rate and burstiness is decided per application. I am interested
>in how these paramters are used by the
>network management to  make  a connection.
>
>thanks
>
>amitava
>
Well, peak rate is fairly easy to determine for something like a
variable bit rate voice or video, if you understand the coding scheme.
Burstiness hasn't been well defined, although some use peak-to-mean
bit rate, some use variance, and many others.

One of the most promising is bandwidth allocated by aggregating calls
of the same service class.  There are many methods by which
we can determine the bit rate characteristics of aggregates of several
homogeneous sources and summing these with other classes of service, we
can determine if a new call can be accepted while maintaining an acceptable
quality of service.

The new issue of IEEE Network (Sep 92) is on congestion control. While I have
not gone through this yet, it looks like some of those articles
may help in answering your question.


--
Duke P. Hong
duke@valentine.uci.edu
Newsgroups: comp.dcom.cell-relay