From:    Charles Hornig

To:      MTB Distribution

Date:    January 26, 1983

Subject: Problems with MCS (MTB-607)

                             ABSTRACT

This MTB discusses the state of the Multics Communications System
(MCS)  as it  is expected to  stand at  the end of  the MR10 time
frame.   There  are  many  problems  with  this  critical Multics
subsystem.  The  time has come  to take a fresh  look at Multics'
communications needs and step out into the 1980's.

This is the first of a  series of MTB's considering the future of
MCS.   Future  MTB's will  discuss  requirements for  MCS  in the
1980's and propose a plan for meeting these requirements.

                             COMMENTS

The  Forum  meeting  "New_MCS"  (short name  "new_mcs")  has been
created on System-M in >udd>Multics>Hornig>meetings to facilitate
discussion of this topic.  If  possible, please use this forum to
make  any comments  on this  MTB.  If you  do not  have access to
System-M, please send mail to  "Hornig -at MIT-Multics" or via U.
S.  Mail to:

   Charles Hornig
   Cambridge Information Systems Laboratory
   575 Technology Square
   Cambridge, Massachusetts 02139-1986

_________________________________________________________________

Multics  Project  internal  working  documentation.   Not  to  be
reproduced or distributed outside the Multics project.


MTB-607                 PROBLEMS WITH MCS                01/26/83

                    THE CURRENT IMPLEMENTATION

MCS,  as  currently  implemented,  may  be  divided  into several
distinct  parts.   These are  the code  running in  the Front-end
Network  Processor  (FNP),   the  "ring-zero  multiplexers",  the
"ring-zero  TTY DIM",  the user-ring  I/O modules, administration
and  control,  and debugging  support.   These will  be described
below.   For  more  detailed  descriptions,  consult  the MULTICS
COMMUNICATIONS SYSTEM SYSTEM  DESIGNER'S NOTEBOOK (AN85), MULTICS
MENU CREATION FACILITIES (CP51),  the MULTICS PROGRAMMER'S MANUAL
-- COMMUNICATIONS (CC92), and  the MULTICS ADMINISTRATOR'S MANUAL
-- COMMUNICATIONS (CC75).

                                Front-end Network Processor (FNP)

The FNP is a dedicated minicomputer which controls communications
lines  for  a Multics  system.   It is  connected to  the central
system through a Direct Interface (DI) channel to the IOM.

Multics  supports two  models of the  FNP.  The  Datanet 355 (now
known as  the Datanet 6632) provided  the original communications
support when  Multics moved to  the 6180 processor.   The Datanet
6661   (and   its   predecessor,   the   Datanet   6678)   are  a
reimplementation of the 355  architecture using the technology of
the Level-6 minicomputer.  The 355  and the 6661 differ primarily
in their extended memory implementation and in the elimination of
the Low-Speed Line Adaptor (LSLA) on the 6661.

There are  also two versions  of the FNP  code.  One is  a frozen
older version than runs on both the 355 and the 6661 using 32K of
memory.  The current version runs  only on the 6661 with 64K-256K
of  memory.   While there  are many  differences between  the two
versions, their broad structure is the same.

The  FNP  code consists  of a  scheduler; utilities  for managing
buffers and  other useful things;  device drivers for  the Direct
Interface Adaptor  (DIA), Line Adaptors (HSLA  and LSLA), and the
FNP  console;  an  interpreter  for  the  "control  tables";  the
"control tables"  themselves; debugging support  (breakpoints and
tracing);  and  initialization  code.   All FNP  code  is written
entirely in 355MAP, the 355  Macro Assembler.  In most cases, the
communications  protocols  are  implemented  as  "control tables"
which  are  interpreted, rather  than  actual machine  code.  The
following protocols are supported:

   * Asynchronous ASCII
   * IBM 1050
   * IBM 2741
   * ARDS
   * Honeywell G115
   * BISYNC
   * Terminet 1200/202 modem


MTB-607                 PROBLEMS WITH MCS                01/26/83

   * Honeywell VIP
   * X.25 level 2
   * IBM 3270
   * HASP

Support is also provided for  Automatic Calling Units (ACU's) and
the COLTS on-line T&D's.

In total, the FNP code contains about 40000 lines of 355MAP code.

                                           Ring-zero Multiplexers

The ring-zero multiplexers provide a framework within the Multics
supervisor for implementing multiplexed communications protocols.
They were  created when the  need for support  for such protocols
became  clear.  Adding  support for multiplexed  protocols to the
FNP  was  considered  impossible  without  a  complete  redesign.
Within this framework, support currently  exists for the IBM 3270
(BSC version), VIP  77XX, X.25 level 3, and  HASP protocols.  The
framework  is  also used  to support  communication with  the FNP
itself and for the software terminal facility.  This code largely
runs in a ring-zero masked and wired environment.  It consists of
about 25000 lines of PL/1 and a small amount of ALM.

                                                Ring-zero TTY DIM

The  ring-zero TTY  DIM provides an  interface between outer-ring
processes  and the  multiplexer hierarchy.  It  also provides, on
request,  most  of the  standard Multics  terminal functionality.
Canonicalization, erase  and kill processing,  escape processing,
translation  and conversion  on both  input and  output, and echo
negotiation are all done here.   Originally written to perform in
a  simple  line-at-a-time  environment,   it  has  been  enhanced
piecemeal to support more  sophisticated terminal functions, such
as the window/video system and  emacs.  It consists of about 7000
lines of PL/1 and a small amount of ALM.

                                            User-ring I/O Modules

The  MCS  I/O modules  which run  in the  user ring  are bisync_,
g115_, hasp_host_, hasp_workstation_, ibm3270_, and tty_.  All of
these modules make use of the interface provided by the ring-zero
DIM.   In  addition,  the  Answering Service  module  astty_, the
Message Coordinator,  the Transaction Processing  module tp_tty_,
the console_server, the window/video system, and the emacs editor
use  this interface.   All together,  thse amount  to about 30000
lines of PL/1 code.

                                       Administration and Control

Administrative control  of MCS is  largely done by  the Answering
Service through the module multiplexer_mgr_.  This program uses a


MTB-607                 PROBLEMS WITH MCS                01/26/83

large installable  table, the Channel Definition  Table (CDT), to
control its operation.  Tools also  exist to compile, update, and
display this table.  Another installable table, the Terminal Type
Table  (TTT),  contains  information  used by  the  user-ring I/O
modules and  by the ring-zero  TTY DIM to  control their behavior
for  different terminals.   Similar tools exist  to maintain this
database.

A large body of metering tools  also exist.  Both the FNP and all
ring-zero   code   meter   their   operation   extensively.   The
system_comm_meters  and channel_comm_meters  programs report this
information  in  human-readable   form.   The  adminitrative  and
metering code amount to about 15000 lines of PL/1.

                                                        Debugging

Tools  also  exist  to  facilitate  debugging  of  communications
problems.   These  include  interactive  debug  of  the  FNP with
debug_fnp, tracing of events in ring zero with trace_mcs, display
of  ring zero  databases with  tty_dump, and  crash analysis with
tty_analyze.  About 15000 lines of PL/1 are devoted to debugging.

                         CURRENT PROBLEMS

Many  problems exist  with the  current implementation.   Most of
these can be traced to attempts  to adapt the software to perform
functions which were not anticipated at the time it was designed.
This is especially apparent in the  FNP, which is the oldest area
of  the  system and  the most  difficult in  which to  make major
changes.  It also  applies to some extent to  the ring-zero parts
of  the system.   The user-ring code  has been  largely immune to
this  problem, since  it can be  more easily  replaced.  This, in
fact, has happened.  The tty_ module, emacs, and the window/video
system  each use  completely different  implementation to perform
essentially  parallel  functions.    The  existing  problems  and
limitations will be discussed in more detail below.

                                                     FNP Problems

As  described  above, the  problems with  the FNP  are especially
severe.  These begin with the Datanet 6661 hardware.  The machine
architecture,   with  its   two  accumulators   and  three  index
registers, is  remarkably weak by today's  standards.  This makes
it  extremely  difficult to  program,  in comparison  with modern
minicomputers.   No programming  languages other  than 355MAP are
available  for it.   While it  can support  256K 18-bit  words of
physical  memory,  its virtual  address space  is limited  to 32K
words.  Use of extended memory requires continuous tinkering with
the pager, again increasing the  complexity of programs.  Its I/O
architecture  also  limits it  to three  simulated HSLA's,  for a
maximum of 96 supported lines.  It  also will not support the new


MTB-607                 PROBLEMS WITH MCS                01/26/83

communications  hardware being  developed for the  DPS-6, such as
the high-speed Single-Line Communications  Channel (SLCC) and the
New Multi-Line Controller (NMLC).

These problems are carried over in the software.  While the basic
structure of the FNP software was well-suited to the needs of the
time it was  written, it has not adapted well  to those of today.
The addition  of breakall and oflow  modes, echo negotiation, and
buffer preallocation have  significantly increased the complexity
of  the  system  because  of their  need  to  circumvent existing
mechanisms.  This has resulted in large parts of the FNP software
being essentially unmaintainable.  Fixing  even minor problems in
areas,  such  as  the  HSLA  status  processor,  which  have been
extensively modified requires a very large investment in time and
energy by the  developers.  Readers of TR phx09129  will note the
many problems with output flow control as an example of this.

We  are  also running  into  the performance  limits of  the 6661
processor.   Work with  X.25 has  already run  into problems with
bursts  of  input  completely  saturating  a  FNP.   While buffer
preallocation  has  alleviated the  problem  of burst  loads, the
trend  towards  more   sophisticated  terminal  interaction  will
continue  to  increase FNP  loads  until the  6661 can  no longer
support them.

                                             Multiplexer Problems

The  multiplexers  have  their  problems  too.   The  multiplexer
hierarchy  was  conceived  as a  means  to permit  support  for a
variety  of  hardcore  multiplexors  within  a  common framework.
Within those bounds it  has succeeded.  However, the architecture
is  not  well adapted  to  supporting more  modern communications
network protocols.  Its static  database allocation requires that
all  attributes of  each subchannel be  declared at  the time the
multiplexer is  configured.  While this is  appropriate for a VIP
controller  or  even  a  FNP,  it  is  totally  inappropriate for
packet-switched  or  local-area  networks.   In  these  networks,
connections   are   created   and   destroyed   dynamically,  not
preconfigured.   Current  attempts to  support X.25  properly are
running into serious difficulties with this problem.

                                                 TTY DIM Problems

The  problems  here  are due  to  the  need to  add  new terminal
management functions to a program poorly arranged to handle them.
The new functions added have been primarily for support for emacs
and the window/video system, and include echo negotiation, marks,
and  the  'write  whole  string' capability.   The  TTY  DIM also
provides  only a  stream interface  to user-ring  programs.  This
makes dealing with record-oriented devices difficult.  Also, many
terminal  management  functions are  driven  from the  TTT.  This


MTB-607                 PROBLEMS WITH MCS                01/26/83

table-driven  approach  has  proved   unable  to  deal  with  the
capabilities of modern terminals.

                                               User-ring Problems

Since user-ring programs  can be replaced by the  user, we do not
see the  lack of functionality or  excessive complexity described
above.   Instead, we  see many  parallel attempts  to provide the
same function.  Each of the  Answering Service, the emacs editor,
and the window/video system has  its own replacement for the tty_
I/O  module.   This duplication  creates its  own maintainability
problems.

                                       Administration and Control

As has  been noted above,  the static CDT and  TTT structures are
not   well   suited  to   the  more   complex  needs   of  modern
communications   processing.    Better  support   of  distributed
networks   will  require   drastic  changes   in  the   way  that
communication functions are administered.  It must be possible to
reconfigure  all  aspects  of  a  communications  channel without
affecting the operation of other channels.

                                           Debugging and Metering

This  is  our  one  strong point.   The  extensive  debugging and
metering support in MCS cannot be faulted.

                        NEW FUNCTIONALITY

At  the present  time there  is a  great deal  of demand  for new
communications functionality.  This demand is coming largely from
two sources,  the window/video system development  effort and the
expansion of  Multics networking capabilities.   The window/video
system  needs  real-time  input  editing  without  central system
overhead.  Network  implementors need extremely  high throughput,
better response time, and also less overhead.  These needs cannot
be met within the current system.   They can and should be met by
any replacement for it.

Another  requirement which  must be  met is  that the replacement
allow much  more architectural flexibility then  the current MCS.
We  need  to  support a  wide  variety of  Honeywell  and foreign
equipment  through   many  different  communication   media.   In
addition,  the  concept  of  'distributed'  front-end  processors
should be  supported.  This would permit  processing performed by
the FNP  to be done  by a FNP at  a remote site.   This FNP would
communicate with  the local Multics  FNP over any of  a number of
communications   media.     This   allows   us    to   distribute
communications processing power where it is needed, and eliminate
unnecessary communications overhead.