From: varney@cbnewsd.cb.att.com (Al Varney)
Subject: Re: Network Connections over ISDN
Organization: AT&T Network Systems, Lisle, IL
Distribution: na
Date: Fri, 14 Aug 1992 20:41:22 GMT

In article <1992Aug14.144656.1934@digibd.com> dror@digibd.com (Dror Kessler) writes:
>In article <1992Aug12.085917.5543@ericsson.se> etxorst@eos.ericsson.se writes:
>>
>>In a real-life situation a message of 1024 bytes (the size limit we'd
>>arbitrarily picked for our message transfer function) took several
>>seconds (often 5 - 10). At 16 kbit/s it should only have needed 0.5 s.
>>I think part of the delay may have been due to flow control imposed by
>>the CO.
>>
>
>Are you reffering to D channel packet (X.25) or Q.931 user-to-user signalling?
>
>Using D channel X.25, I have seen close to 14000 bps of user data. 

   Hmmm, why did I only get 1333 bytes/sec (10664 bits/sec.)  Or did you
mean 1400 bytes/sec, times 10 to make it comparable to modem "bauds"?

>Q.931 user-to-user signalling is not intended to move large amounts of
>information. The main use would be signalling setup information user-to-user
>upon connection establishment. Trying to move data with this facility is
>asking for it.

   Depends on the amount of data and the application -- for interactive
applications that also involve voice (ranging from catalog sales to
customer support to ticket sales to helping a friend use his/her PC),
the D-channel and the ability to coordinate voice services with it
is hard to beat.  For fast/short/bursty transfers (say credit card
validation, remote meter reading or reading E-mail/netnews), it works
as well or better than other methods -- call set-up at the right data
rate is well below 1 second for intra-switch or switch-to-packet
network (depends on the packet network).  The T2500's I tested took
about 10 seconds to agree on a speed.

>After saying that, I would like to point that data transfer on the D channel is 
>becoming less and less interesting. have you ever thought of how much you're 
>going to pay for this service LONG DISTANCE. With circuit switched B channel, 
>you're paying a rate comparable to analog long distance.

   Depends on who/how you call.  Our implementation of D-channel (and
X.25 B-channels) supports X.75/X.75' calls to packet networks, meaning
that the USA could finally get direct end-customer access to the packet
network world that Europe has been using for years.  A direct X.25 T1
channel to a CO would be the best claim I know of for Compuserve, etc.
to continue to sidestep the payment of IC access charges -- it would
really be different than the IC's voice trunk interface, unlike today.

   And the PAD is in your ISDN card/TA, where you control it's capabilities,
such as window size, packet size, number of simultaneous connections, etc.
I believe today's D-channel interface will support 8 different devices
(TEIs) using X.25, so you could have simultaneous connections to 8
physical devices (or 8 ports on a PC) each running at 9600 baud, so long
as you were willing to live with the delay imposed by the D-channel's
capacity.

   That said (and it was far too much), I agree that if your goal is
bulk data transfer or a similar bandwidth-hog, D-channel isn't for you.
B-channel packet or 64Kbps data makes a lot more sense.  And if it's a
long-term, high-speed pipe you want, why not just go private line?
The standards folks are really moving on 384Kbps and 1544Kbps these days.
Want to bet we'll have folks complaining that 1.5Mbps is "too slow"
in a few years?  I've gotten one already that suggests that 300Mbps
is "too slow" - David Lewis is right; someone will fill up bandwidth
as fast as it's available.  Wanta' download "Rocky XXVI"?

>Also user-to-user 
>signalling can not be guaranteed unless there is end-to-end ISDN (SS7 in US) 
>deployment, which is always to be completed in two years.

   While US West may be a little slow with SS7 (they have more LATAs
to cover, etc.), there are other areas that are virtually all SS7 for
intra-LATA calls.

Al Varney - just MY opinion.
Newsgroups: comp.dcom.isdn