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

In article <o7jfnjs@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Aug6.025730.25315@cbnewsd.cb.att.com>, varney@cbnewsd.cb.att.com
>(Al Varney) writes:
>> ...
>>    I wasn't involved in any ISDN "trials", but I will say that D-channel
>> packet is not a problem at 9600 or 19.2K for me, using a PC + terminal
>> emulator.  With hardware flow control on, file transfers with Zmodem or
>> Kermit are fault-free, regardless of the other D-channel activity, such
>> are receiving incoming B-channel voice calls or using the Directory
>> Look-up service.  It works just like "packet" should.  Note that at the
>> 19.2K PC-to-TA interface speed, there is flow control required on every
>> few hundred bytes.

>I do not understand.
>What does "not a problem" mean?  How fast were full-screen updates?
>In seconds for a reasonably full screen?

   Screen updates are faster than I can measure easily.  They look
and feel just like screen updates on direct-connect systems.  The
only problems I know of are that at 19200 baud, the D-channel delays
can cause problems to systems that think 19200 implies something about
how long it takes to transmit a byte end-to-end.  These systems would
also be the ones that have problems with 19200 via satellite.  In fact,
that would be a good comparison -- what file transfer protocols will
work with such delays?

>How fast were your Zmodem and kermit file transfers?  In net Bytes/sec?

   See below -- I want to cover some other stuff first...

  [I deleted B-channel multiplexing description]

>How much will that cost?  Will it be billed by the packet?  At rates
>as outrageous as D-channel?

    Sorry, I'm a User, not the bill-payer.  I have no idea,
and don't care much, what the rates are.  I do know the Comp.
Center and Telecom folks here are pretty frugal.  But we do
have a diverse community of users and systems, all intermingled.
We have about 10,000 ISDN users in a "complex" of several buildings,
with most having AT&T ISDN 7506 terminals for voice and D-channel
data access.  There are also lots of "local" networks of various
speeds/sizes, and data users that range from clerks and secretaries
using PCs using D-channel data to access UNIX(rg) and an AT&T Mail
interface, to the usual "developer" using workstations connected
to both dedicated equipment and the larger data network.

   In most cases, we use Datakit(tm) Virtual Circuit [packet] Switches
to reach remote (out of building) systems and systems that don't
provide an easy connection to an X.25 B-channel.  Many larger
systems have direct ISDN telephone numbers leading to B-channel
interfaces.  Datakit ports are just another number you "dial" for
data calls -- it's arranged as a huge hunt group.  In addition, we
can (obviously) use the D-channel to set up a data call between any
two ISDN sets -- sometimes useful for PC-to-PC data transfer or
"dumb terminal" access to a computer's serial ports.

>> >..., but some of use are interested in the bits/sec number because
>> >we have concrete applications that need certain minimum rates.

   But what if the bit RATE is above the minimum, but there was
an over-all 2 second latency in transmission?  Could an even
higher speed compensate, or are there things (such a echoing of
a typed character) where the bit rate is not critical, but the
transmission delay is very important?

>As in most computer things, no single figure of merit is really
>sufficient.  However, in this arena, latency and throughput are good
>enough.  Any honest measure of encompasses congestion, retransmissions,
>slow-start, and so on.

   Well, I didn't run any BIG tests.  These were run at various
times and on various PC-clones, as I "found" time.  My comments
will be {bracketed like this} in the information below.  These
are tests using various PC-based common file transfer protocols,
without compression, using a large text file of only "normal"
characters.  I timed them under various conditions, and used my
watch to determine a Characters Per Second (CPS) rate.

  For comparison purposes, I tested file transfers using 2 common
(for me) configurations that were not ISDN.  All cases used "EIA"
hardware flow control -- XON/XOFF was disabled.

-----

    Telebit T2500 modems, 9600 baud using PEP, call across the room
Kermit (non-sliding window, 1000 byte packets), no emulation      425 CPS
Kermit (non-sliding window, 90 byte packets), Kermit emulation    640 CPS
  {S110=10}
Procomm Plus(rg) window Kermit, 1 byte LRC, 1000 byte packet      755 CPS

-----

    Datakit VCS 9600 baud direct connection to UNIX mainframe
      {medium load, 290 users, 145 using "layers"}
Kermit (non-sliding window, 1200 byte packets), upload            784 CPS
Kermit (non-sliding window, 1200 byte packets), download          709 CPS

------

    Datakit VCS 9600 baud connection to UNIX mainframe,
     via ISDN D-channel at 9600 baud {delays from both}
Kermit (non-sliding window, 1200 byte packets), upload            656 CPS
Kermit (non-sliding window, 1200 byte packets), download          612 CPS

------

    PC-to-PC, 9600 baud to D-Channel
Kermit (non-sliding window, 1000 byte packets)                    601 CPS
Procom Plus vers. 1.1B, window Kermit, 1024 byte packets          725 CPS
Procom Plus vers. 1.1B, Ymodem-G                                  940 CPS
Procom Plus vers. 2, window Kermit, "relaxed timeouts"            930 CPS
Procom Plus vers. 2, Zmodem streaming, "relaxed timeouts"         930 CPS

------

    PC-to-PC, 19200 baud to D-Channel
Kermit (non-sliding window, 1000 byte packets)                    960 CPS
Procom Plus vers. 1.1B, window Kermit, 1024 byte packets          xxx CPS
  {Unreliable, many time-outs, around 1133 CPS when it worked}
  {Making EITHER to 9600 baud eliminated time-outs - about 750 CPS}
Procom Plus vers. 1.1B, Ymodem-G                                  xxx CPS
  {Unreliable, many time-outs, around 1190 CPS when it worked}
Procom Plus vers. 2, window Kermit, "relaxed timeouts"           1333 CPS
Procom Plus vers. 2, Zmodem streaming, "relaxed timeouts"        1240 CPS
  {About 1 error per 10K bytes!!}


------

   I didn't measure latency directly.  I don't have any fancy test
equipment...  The engineering documents state that internal switch
processing delay is on the order of 2-5 msec. between receipt of
last packet byte and queuing the packet for transmission.  The upper
figure is for handling 200 packets/second (the packet processors
are shared by many BRI lines).  A similar delay is encountered
at the receiving line.  At 19200 baud, a delay of 5+5=10 msec. is
about 20 characters.

   A much bigger delay is introduced by the operation of the packet
assembler in the terminal.  In the default (tested) mode, a full
packet of 128 bytes will be collected before transmission.  This
is because of an algorithm that waits about 10 msec. for more
data, before sending a packet.  Unless you type faster than 10
characters/second, you won't notice this on input.  But for computer-
generated streams of bytes, it will introduce a delay of about 128
character times -- about 60 msec.  So a total delay of around 70 msec.
would be a good estimate.  (I've never noticed any "jerky" screen
updates that I blamed on ISDN -- usually the byte stream from the
UNIX host has a lot more delay and variability.)


>Why does it sound as if you don't want bit rates to be considered?

    Well, I'm not an expert, so deriving "bit rates" for a packet
network is difficult for me.  Anyone got any "magic" formulas?
The easy way would be to say that (from the above) Ymodem-G at
9600 baud gets 940 chars/sec. (Is that 9400 baud? or just 7520 bits/sec?)
19200 baud gets 1333 chars/sec, which is about the maximum you can
expect with the packet overhead on the D-channel.

   Sorry it took so long to reply.  I will get to the other follow-ups
soon, I hope.

Al Varney - just MY opinion.