HDTenEightyP/NetNews huggingface dataset:
From: scott@labtam.labtam.oz.au (Scott Colwell)
Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Mon, 11 Jan 1993 02:48:35 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <C0Gn8s.721@world.std.com>, ariel@world.std.com (Robert L Ullmann) writes:
>> ...
>> It takes a _lot_ of peak-power CPU to keep the output going at
>> 64kpbs at a high compression ratio, even if the _average_ CPU
>> is small.


>Is it a big deal for an 8088 or even 68000 in a modem doing v.42bis?

Depends on the data rate.  Clark Thomborson gave some figures in an
article in IEEE Micro (Oct '92 issue, pages 41-53, "The V.42bis Standard
for Data-Compressing Modems")  My interpretation of his article would
indicate that you should get ~10kbyte/s from a 68k with some tuning and
maybe 100kbyte/s from something like a i80960SA (an educated guess though)

>I assume it's somewhere in between, but where?  How many cycles per
>byte output is "a _lot_"?  With familiar, various assumptions about the
>character of the data stream, what are the average, median, and peak
>cycles/byte for
>    - v.42bis with the various dictionary sizes
>    - splay trees
>    - LZW
>    - anything else

The above article compares V.42bis of different dictionary sizes and a
number of other compression schemes for compression ratio.  He also discusses
the storage requirements and execution rates in the text but does not provide
them in detail.

>I guess the memory requirements for all reasonable compress schemes
>are in the few KByte/data stream range.  Is that a good guess?

Clark's article suggest some require 100s of kbytes but some also only
need <10kbytes.
-- 
Scott Colwell				Labtam Australia Pty. Ltd.
net:	scott@labtam.labtam.oz.au	41 Malcolm Rd., Braeside
phone:	+61-3-587-1444			Melbourne, Australia  3195
Newsgroups: comp.dcom.isdn
From: ariel@world.std.com (Robert L Ullmann)
Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Organization: The World in Boston
Date: Thu, 7 Jan 1993 01:38:51 GMT

jeff@is.s.u-tokyo.ac.jp (Jeff McAffer) writes:
> I am not sure that I understand the compression problem.  There are
> several schemes available that do on the fly compression on data to
> disk.  The data rates are significantly higher and they actually make
> the disk interaction faster.  That is, the amount of time saved
> reading bytes is greater than the extra required to de/compress.
> Given that 64kbits/s is at least a couple orders of magnitude less, I
> would have thought that this would not be an issue.  How are the cases
> different?

I can point to one serious difference; whether it is relevent or
not I don't know.

In the disk case, the compression can use varying amounts of CPU
(lots for these few Kbytes, only a little for the next 200 K), and
you see the average over a large amount of data. It also (more
importantly) has the freedom to take the data as it can, and write
it to disk when it is ready.

In the communications scenario, the compression not only has to
operate at a constant rate, it has to do the constant rate on
the _output_ side. This is much more difficult. Even largish
data buffers (~100Kbytes) don't help very much. The output of
"conventional" compression algorithms (like the disk uses) is
highly variable in bandwidth.

Yes, you say: compress the data, then buffer it to the output
line, sending it at 64kbps. Ah, but that takes a highly variable
amount of CPU. In particular, the CPU demand _peaks_ much higher
than it averages. If you truncate the peaks, you lose compression
ratio as your buffer empties.

It takes a _lot_ of peak-power CPU to keep the output going at
64kpbs at a high compression ratio, even if the _average_ CPU
is small.

One way to fix that is to design an algorithm with a flatter
CPU/ratio curve; I suspect that is what France Telecom has
done.

Rob

--
Robert Ullmann		Ariel@World.STD.COM	+1 508 879 6994 x226
Quand Maigret poussa la porte du Tabac Fontaine, vers une heure et demie,
le patron du bar, qui venait de se lever, descendait lentement un escalier
en colimaon qui s'amorait dans l'arrire-salle. ... Arriv derrire le
comptoir, il repousa le garon d'un geste ngligent de la main, saisit
une bouteille de vin blanc, un verre, mlangea au vin de l'eau minrale et,
la tte renverse en arrire, se gargarisa.  -- Simenon

Xref: sparky comp.dcom.isdn:1111 comp.protocols.ppp:1055
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.dcom.isdn,comp.protocols.ppp
Subject: Re: dp2.2 on Interactive V3.2 & ISDN
Date: 8 Jan 1993 23:33:16 GMT
Organization: University of Michigan CITI
Distribution: world
Reply-To: Jim.Rees@umich.edu
NNTP-Posting-Host: pisa.citi.umich.edu

In article <C0K1EC.E0v@world.std.com>, ariel@world.std.com (Robert L Ullmann) writes:

  Ah, there are 3 (FR, PPP, X.25); and only X.25 is full-standard
  in both Internet and ISO/CCITT...
  One of the reasons you don't hear too much about X.25 is that it is _done_,

Actually, the reason you don't hear much about it is that running ip over
x.25 is too horrible to contemplate, even worse than ip over ppp.  It's
something people did back in the dark ages when x.25 was the only available
public data network in some countries, but it has no place in ip over isdn.
Newsgroups: comp.dcom.isdn
From: laubach@hpl.hp.com (Mark Laubach)
Subject: Re: NT1 - Where to get?
Date: Sun, 10 Jan 1993 05:43:08 GMT
Organization: Hewlett-Packard Laboratories Palo Alto,CA
X-Newsreader: TIN [version 1.1.4 PL6]

Our networking folks tell me they are ordering from:

	GTE Supply
	Atlanta Sales Center
	2580 Cumberland Parkway, NW
	Atlanta, GA  30339

	800-433-4837


I've gotten them previously from another source, but this is a 
better one.

--
Mark

Newsgroups: comp.dcom.isdn
From: sfrazier@norstan.com (Superuser)
Subject: ISDN & the PBX
Organization: Norstan Communications - Columbus, Ohio
Date: Sat, 9 Jan 1993 13:50:28 GMT

I understand that some PBX's offer (and more will offer) 2B+D from
the PBX.  I understand that the concept behind this would allow the
person who comes to the office everyday with his/her station and computer
could (soon) "work out of their home".

It is not difficult to understand how a Telco offering to the home would
work with ISDN, but how about if that person needed his/her phone/data
connection to his/her home?

Let's say the PBX could offer the same thing that a centrex/business line
could from the TELCOO.  How would you get this person's extension and
computer to his/her house?  Obviously if the person was located on the
same premise you would run a copper pair to that person's house, but
let's say that person was located about 1/2 mile away.  what would
be needed and what would you order from the TELCO to make this happen?

Thanks in advance.

Steve


-- 
Norstan Communications, Inc.        | Steven E. Frazier
8101 N. High Street Suite 100       |---------------------------------------
Columbus, OH   43235                | Local : sfrazier
Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com
Newsgroups: comp.dcom.isdn
From: "Bob Larribeau" <p00136@psilink.com>
Subject: Re: PPP on multiple B channels
Organization: Consultant
Date: Tue, 5 Jan 1993 23:28:35 GMT
X-Mailer: PSILink-DOS (3.3)

>DATE:   4 Jan 1993 16:31:36 GMT
>FROM:   David E. Martin <dem@fnal.gov>
>
>In article p00136@psilink.com, "Bob Larribeau" <p00136@psilink.com> writes:
>>Is there any work going on to define how to support PPP on more than one 
>>B channel or has this problem already been solved?  The most important 
>>case is probably to support PPP on 2 B channels.
>>
>
>You probably don't want PPP to know about the number of channels.  Why not use
>something like BONDING (bandwidth-on-demand internetworking group).  Then present
>the aggregate bandwidth to PPP?
>

What I am asking about is a standardized approach that will assure 
interoperability.  Using PPP over BONDING sounds like a fine approach.  
Is it being adopted as the standard approach by the IETF?

		Bob Larribeau
		San Francisco

P.S., I tried mailing to you directly but the mail was returned.
Newsgroups: comp.dcom.isdn
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: Re: IDSN wanna-be questions
    <1993Jan9.012826.14525@hplabsz.hpl.hp.com>
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International
Date: Sat, 9 Jan 1993 10:44:59 GMT
X-Bytes: 1443

In article <1993Jan9.012826.14525@hplabsz.hpl.hp.com> laubach@hpl.hp.com (Mark Laubach) writes:

 |There are two solutions I know of to link a PC at home with work over ISDN:
 |
 |1) Buy a pair of Combinet ISDN Ethernet bridges (~2K ea) and put small 
 |   ethernet at home bridged to an ethernet segment at work.  This works 

 |2) HP, as one example, makes an AT-bus ISDN card for the PC.  It provides
 |   2B access to ISDN and requires a similar setup at the work end: i.e.,
 |   ISDN card in a PC with SCO Unix providing a routing function between
 |   the ISDN card and an ethernet segment.

Is it absolutely necessary to have two of the same hardware?  I have
one lab full of machine dependent (i.e., SBus, NuBus...) (no PCs) ISDN
cards/boxes and am hoping to find an IDSN/ethernet bridge/router for a
remote (PC based) lab that will allow me to talk TCP/IP to at least
one of them.

Is there any easy way to tell if two ISDN devices are compatible?
That is, if I will be able to use TCP/IP?

A bit aside, how do you control the bridge?  I assume that you need
some sort of software running somewhere that sends
control/configuration data over the ethernet.  True?  If so, is this
software typically available for DOS boxes?

Is it easy to configure them (the bridges) to multiplex two 64K
channels?  To drop the line during idle time?  Is this transparent to
the ethernet?

Thanks for your help.

--
ato de, |m        -- gad!  winter!
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.dcom.isdn
Subject: Re: IDSN wanna-be questions
Date: 11 Jan 1993 19:11:55 GMT
Organization: University of Michigan CITI
Distribution: world
Reply-To: Jim.Rees@umich.edu
NNTP-Posting-Host: pisa.citi.umich.edu

In article <1993Jan10.135914.12321W@lumina.edb.tih.no>, ketil@edb.tih.no (Ketil Albertsen,TIH) writes:

  I want my PC to present the name of the caller on the screen, if known, 
  before I lift the receiver...

Caller-id returns the number of the phone used to place the call.  This does
not necessarily imply anything about the name of the person making the call.
You should be aware of the limitations of caller-id before implementing
this kind of screening.
Newsgroups: comp.dcom.isdn
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: Using a PC and ISDN
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International
Date: Tue, 5 Jan 1993 12:32:01 GMT
Distribution: comp
X-Bytes: 1017

I would like to connect my PC any one of a number of remote machines
using ISDN (SPARC, Sony NeWS, Mac) each of which has its own ISDN
board/hardware.  Over the connection I would like to be able to do
things like run X, transfer files...  It would be good if the ISDN
link could just be made to look like a TCP/IP connection and packets
be transparently gated and routed.

The question is: What do I buy for my PC (hardware and software)?
What do I have to look for?  Be careful of?  

I already have FTPs TCP/IP software for the PC but assume that I need
something (packet driver?) under that and over the IDSN device.

If I understand TAs right there is not much point in them as I could
do just about as well with a 14.4K analog modem.  Consequently I am
really only interested in setups which give me 64kps.  128K with
multiplexing would be even better.  auto disconnect during idle times
would be great as we pay for phone connect time here.

Thanks alot for your help.
--
ato de, |m        -- Death by stereo!
Newsgroups: comp.dcom.isdn
From: picone@trdc000.trdc.ti.com (Joe Picone)
Subject: Re: end-to-end digital connections on ISDN
Originator: picone@trdc000
Organization: Tsukuba Research and Development Center
	<1993Jan6.213355.20207@cbfsb.cb.att.com>
Date: Thu, 7 Jan 1993 00:52:50 GMT

> I don't doubt that they can guarantee that the connection is fully digital
> from your lab, to the serving MCI switch, through the MCI network, to the
> far-end MCI switch, and even as far as the facilities from the far-end MCI
> switch to the LEC Point of Termination/Point of Interface.  However, it is
> physically impossible for an IXC to guarantee *anything* with regard to
> whether connections beyond the POI are digital or analog or how many D/A-A/D
> conversions a signal will go through.
> 
> For instance, the IXC may be able to guarantee that all access facilities
> (from the LEC network to the IXC network) are digital.  However, they can
> not guarantee that all Access Tandems are digital.  The connection could go
> from an MCI DMS-250 (digital) over digital facilities to a 1AESS(tm) switch
> AT (analog SPC) (1 D/A-A/D), then over analog facilities to a DMS-100 EO
> (digital) (another D/A-A/D) serving an analog loop (a third D/A-A/D).
> Unless MCI is claiming that they have direct access trunks to all digital
> EOs in North America, their claim rests on LEC network topology, which is
> outside their control.  And I feel certain that somewhere in North America
> there is at least one digital EO with trunks to an analog SPC AT with
> connections to MCI...

Sorry, I forgot to add an important detail. We supply the callers with
a toll-free 800 number which, I assume, connects them directly to our
carrier (MCI) at the local office (equal access, right?).

So, in this case, doesn't this guarantee end-to-end digital if all of
the carrier's access facilities are digital?

How would ISDN compare (still the same as T1)?

Or is it still possible that in reaching an MCI toll-free number from some
areas, you may go through some tandem encodings?

-Joe
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Organization: Corporation for Open Systems
Date: Tue, 5 Jan 1993 14:30:13 GMT

In <725842056.AA00743@cswamp.apana.org.au> Arthur@cswamp.apana.org.au (Arthur Marsh) writes:

>On Fri 25 Dec at 23:50 Christian Weisgerber wrote: 

> CW> Is V.42bis already defined by the CCITT for use over V.120? 
> CW> I though it was still in the "we're looking into it" 
> CW> stage, which can turn out anything.

>The error correcting procedure of V.120 is an allowed error correction
>procedure for V.42bis, but until V.42bis is revised, there is no defined method
>of negotiating V.42bis parameters in V.120. (The other allowed error correction
>protocol for V.42bis, LAPM has an XID defined for exchanging V.42bis
>parameters).

>So, V.42bis for V.120 is allowed and it's at the "we're looking into it"
>stage.

In their demo at TRIP'92, France Telecom showed me a compression
algorithm (or at least the effects of one) over ISDN. When I asked
if it was V.42bis, they said no. According to the person I was
speaking with, they found V.42bis too processor intensive for a
64 kbit/s line and it actually slowed throughput. They claimed to
be achieving throughput in excess of 110 kbit/s on a 64 kbit/s
line. I didn't have a stopwatch with me, but it certainly looked
impressive. Hopefully, they will submit it to CCITT.

> * Origin: Camelot Swamp MJCNA, Hawthorndene, Sth Australia (8:7000/8)

Bob.


Newsgroups: comp.dcom.isdn
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: IDSN wanna-be questions
Organization: Gandalf Data Ltd.
Date: Mon, 11 Jan 1993 15:14:51 GMT

In <1993Jan9.104506.3842@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp (Jeff McAffer) writes:

>In article <1993Jan9.012826.14525@hplabsz.hpl.hp.com> laubach@hpl.hp.com (Mark Laubach) writes:

> |There are two solutions I know of to link a PC at home with work over ISDN:
> |
> |   ethernet at home bridged to an ethernet segment at work.  This works 

> |2) HP, as one example, makes an AT-bus ISDN card for the PC.  It provides

3) Gandalf 5510 personal bridge;
4) Gandalf 5220 Remote bridge with compression;

>Is it absolutely necessary to have two of the same hardware?  I have
>one lab full of machine dependent (i.e., SBus, NuBus...) (no PCs) ISDN
>cards/boxes and am hoping to find an IDSN/ethernet bridge/router for a
>remote (PC based) lab that will allow me to talk TCP/IP to at least
>one of them.

What exactly do you have in the way of ISDN hardware.  TA's? Internal
SUN cards?

You may need to find a PPP driver compatible with these devices.  If they
are merely TA's, then they can be used with most any bridge.  If they 
have V.25 bis (I think) call control, then our bridge can manage the
links more effectively (see below).

>Is there any easy way to tell if two ISDN devices are compatible?
>That is, if I will be able to use TCP/IP?

Probably only if they both conform to PPP.  However, several bridges
simply encapsulate the Ethernet frame between HDLC flags.  These
devices should work together.  This method is used by our 5510.  If
you want data compression, you are unlikely at this time to find 2 
compatible boxes.  

>A bit aside, how do you control the bridge?  I assume that you need
>some sort of software running somewhere that sends
>control/configuration data over the ethernet.  True?  If so, is this
>software typically available for DOS boxes?

Serial port or via telnet access.  The only DOS program you need is
a vt100 emulation package (part of most comm programs).  Alternately,
you can access the remote end bridge via telnet from the central site.

>Is it easy to configure them (the bridges) to multiplex two 64K
>channels?  To drop the line during idle time?  Is this transparent to
>the ethernet?

Yes.
The 5220i software links can be configured to:

(1) Control both links via time of day;
(2) Idle timeout one or both links;
(3) Raise backup link on failure of primary link;
(4) Recognize remote MAC or IP addresses and raise link only when 
    required.  Remote IP or MAC addresses are entered in a table via
    the console, and saved in battery backed up SRAM.
(5) Raise second B-channel when the sustained load exceeds a user
    programmed threshold;
(6) V.25 bis dialing; 

For more information, call Gandalf Premier at 1-800-354-4224.

Newsgroups: comp.dcom.isdn
From: laubach@hpl.hp.com (Mark Laubach)
Subject: Re: IDSN wanna-be questions
Date: Sun, 10 Jan 1993 05:35:06 GMT
Organization: Hewlett-Packard Laboratories Palo Alto,CA
X-Newsreader: TIN [version 1.1.4 PL6]

By the way, I seem to have given what seemed to be an incomplete statement
in my first posting.  In the case where you are using an ISDN circuit
to link one or two stations at home with your network at work, i.e.,
2B+D to 2B+D, then one could argue that there would be little difference
between a bridge or a router box at the work side of this circuit.

: Is it absolutely necessary to have two of the same hardware?  I have
: one lab full of machine dependent (i.e., SBus, NuBus...) (no PCs) ISDN
: cards/boxes and am hoping to find an IDSN/ethernet bridge/router for a
: remote (PC based) lab that will allow me to talk TCP/IP to at least
: one of them.

As more products become available on the market, I would say that
you'll be able to mix and match hardware. The combinets are bridging
ethernet packets using HDLC over the B-channel(s).  I've not
researched what will interface cleanly to it.  There was another
company showing at Interop (forget their name) who made a similar
product.  There is a nicer option coming of using a NetExpress primary
rate interface box (23B+D) as the work side bridge.  This at least
cuts down the number of duplicate pairs of boxes.  Rumor has it the
primary rate box will be about $20K and will be dependent on primary
rate being available in your area.

: Is there any easy way to tell if two ISDN devices are compatible?
: That is, if I will be able to use TCP/IP?

Again, it depends if the boxes on either side of the circuit speak
the same protocol.  You'll have to contact vendors and ask them.  Over
a generic ethernet bridge, TCP/IP, broadcasts, etc run just fine.

: A bit aside, how do you control the bridge?  I assume that you need
: some sort of software running somewhere that sends
: control/configuration data over the ethernet.  True?  If so, is this
: software typically available for DOS boxes?

The combinet boxes are configured via an RS-232 port with parameters
stored in static ram. The way we have these configured here, the box
will initiate an ISDN call if it senses any traffic on the LAN segment.
There is no protocol running over the LAN segment that will talk to the
bridges.

: Is it easy to configure them (the bridges) to multiplex two 64K
: channels?  To drop the line during idle time?  Is this transparent to
: the ethernet?

Yes, the combinet boxes can be configured to use one or both B channels.
Use of one vs two is transparent to the LAN.  I've got my box configured
to drop the second B channel after 60 seconds idle time and the first
B channel after 120 seconds idle time. I've got Xvision running on my
PC at home and if the ISDN link shuts down completely, then I see about
a 5-8 second pause while a new call is made.  The applications I run,
don't seem to mind this atl all.  All is transparent to the ethernet.

Mark


Newsgroups: comp.dcom.isdn
From: bruce@camb.com (Barton F. Bruce)
Newsgroups: comp.dcom.isdn
Subject: Re: Asynchronous TAs
Date: 12 Jan 93 00:36:35 EDT
Distribution: world
Organization: Cambridge Computer Associates, Inc.

In article <726359409.AA00781@cswamp.apana.org.au>, Arthur@cswamp.apana.org.au (Arthur Marsh) writes:
> There are updates to CCITT V.110 and V.120 approved and shortly to be
> published. I have yet to see them, but would be interested to know if they do
> anything to spell out the maximum DTE rate. After all, a V.32bis modem with
> V.42bis might be expected to support a 57.6 kbps DTE rate.

And an ISDN unit with real 56/64kb available should have no problem with
57.6 (stripping async start and stop bits leaves you with 57.6 x 8/10 of
needed real bandwidth) but you would also expect the v.42 bis to get 
you to at least 115.2kb DTE speed. If a generic modem can compress, the darn
expensive ISDN TA units better if they expect to sell.
From: h198@hosp.med.umich.edu  (Gene Mangum)
Newsgroups: comp.dcom.isdn
Subject: IDSN wanna-be questions
Date: Fri, 08 Jan 1993  09:21 EDT
Organization: Univ of Michigan Hospitals
Distribution: world
NNTP-Posting-Host: condor.hosp.med.umich.edu
X-Newsreader: FTPNuz (DOS) v1.0

Hello ISDN experts,
 
I have two questions.   First, does anyone know of a good review of IDSN
cards for IBM PCs.   Something like PC Magazine would be good for my 
level (know nothing).   And second, does anyone have comments on the
compatibility of the serial interface on the Teleos IDSN card for the
PC.   I understand that it has a 16550 UART.   Does it run with regular
serial port software well, or is it flaky/incompatible?
 
Thanks for any info,

  Gene Mangum
  Univ of Michigan Hospitals
Newsgroups: comp.dcom.isdn
From: sfrazier@norstan.com (Superuser)
Subject: 23B+D (PBX) & 2B+D (Home)
Organization: Norstan Communications - Columbus, Ohio
Date: Sun, 10 Jan 1993 14:11:51 GMT

Would the following work?

Install a 23B+D T1 into an ISDN compatible PBX from the local Telco.
From the local telco install 23 2B+D to 23 individual homes.

The pbx would supply the "dial tone", if you will, the phone number would
be a DID on the PBX.  The individuals could wwork out of their home.  All
23 people could make and receive calls at the same time due to a 1:1 ratio.

If the above will work, then obvious, data to and from the homes should
work as well.

Anyone, please comment if the above would or wouldn't work.

Thanks.


-- 
Norstan Communications, Inc.        | Steven E. Frazier
8101 N. High Street Suite 100       |---------------------------------------
Columbus, OH   43235                | Local : sfrazier
Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com
Newsgroups: comp.dcom.isdn