A meeting of the LNPA-WG's Slow Horse Subcommittee was held 8-12-99
at Portland, Oregon. The meeting was dedicated to development of
LSMS performance and availability requirements needed to avoid
partial failures of NPAC broadcasts. Lockheed submitted a
contribution which helped organize today's discussion.

END-TO-END PERFORMANCE

A question was raised again about need to develop overall end-to-end
performance requirements. This has been proposed in past meetings as
well, but the group has consistently concluded that it will focus
only on LSMS- and SOA-specific requirements.

THROTTLE NPAC BROADCASTS?

One approach considered to reduce pressure on service provider systems
was to make the NPAC the bottleneck, to smooth the peak loads.
The NPAC has flow control based on message volumes, but does not
distinguish between CMIP messages with one TN and CMIP messages with
many TNs; to the NPAC, a message is a message. But this does not
provide a steady stream of messages, merely allows buffering of peak
rates. And failing to recognize TN quantities within the messages
means the feature could not provide the throttle effect being discussed,
even if it did provide a smooth message flow rate.

The service providers' SOA and LSMS equipment vendors expressed need
to have idea of what loads will be offered in order to engineer
their systems to meet those loads. With current design, NPAC passes
through TN transactions as rapidly as it can, with resulting peaks
almost entirely a function of service provider activity. Jim Rooks,
ESI, explained that while a TN-based flow control could be designed
for NPAC, it would have substantial cost in dollars and in
processing capacity.

Another suggestion to suppress peaking was to avoid the use of
ranges for messages to and from NPAC. One result of abandoning
ranges would be a slower delivery of ported number data to service
providers. But peaking still would occur since each provider's SOA
activations are sent independently of one another.

Both of these approaches were discarded for the time being.
There appeared to be some confusion about severity of potential
peaks. ESI pointed out that NPAC must process the TNs, in an
activate for example, before setting up broadcast. Consequently,
even with a substantial series of range messages in a row, peak
TN/second rates would not be a great deal larger than NPAC's
advertised capacity. Informally, ESI suggested the sustained rate of
TN transaction might be about 5 while the peak would be unlikely to
exceed about twice that rate, or 10 TN/second.

A request was made to have Lockheed explain the rate at which LSMS
create messages are sent to LSMS under the 25 TN/second test
scenario. The overall test scenario lasts about 82 seconds, but the
336 TNs apparently are sent to each LSMS over a much shorter
interval, suggesting a much higher TN/second rate must be
accommodated by the LSMS. (Beth Watkins agreed to write up the data
request and forward it to Northeast LLC PE so that he could ask the
LLC to request the data formally from Lockheed.)
Another suggestion was to eliminate the 3x5 timers. That is, partial
failures still would be tracked, but LSMS association would not be
dropped merely because its response was not timely. It was unclear
whether this would be useful approach and no action was taken.

REQUIREMENT CATEGORIES

Three requirement categories were identified: Performance,
Functionality, and Availability. Today's meeting focused on
agreement to the core requirements believed necessary to address the
slow/dead horse problem. That is, the team dealt only with
requirements viewed as needed to reduce partial broadcast failures,
the failures believed due either to LSMS being unable to keep pace
with NPAC, and so losing its association, or LSMS not on line
when broadcast occurs. Only the core LSMS requirements were
discussed today; possible requirements for SOA remain to be considered.

LSMS PERFORMANCE REQUIREMENT

A single performance requirement appears necessary. The proposal
dealt with a basic transaction (an activation) with sustained period
(1 hour) performance level of X (where "X" is the "advertised" NPAC
capacity -- currently X would be about 5) and a peak period (5
minutes) performance level of 2 X (with no recovery period, but with
limit of one peak period occurrence per hour).

Other transaction categories (Modify, Delete, Mass Change) were
discussed. Transaction rate values would be different, probably
lower, than "X." But data on broadcast rate and processing
requirements are not available on these transaction categories and
so transactions other than "activation" are not being included in
the performance requirement at this time.
There was suggestion that the sustained figure should be the same as
the peak figure since the two numbers were similar. This was not
accepted by the group.

John Malyar, Telcordia, agreed to provide text for this requirement
including how it would be tested and measured.

LSMS AVAILABILITY REQUIREMENT

Two methods of defining availability requirement statements were
suggested: The first is mean-time-to-failure paired with
mean-time-to-repair. The second is "percent availability" expressed
as a fraction of time in service during the measured interval,
excluding time set aside for scheduled maintenance. Associated with
the "percent availability" approach is the need for a Service
Unavailability objective, such as could occur for routine
maintenance, non-routine maintenance, and software upgrades.
Unlike the performance requirement, availability is a composite of
LSMS/SOA performance and related systems required to connect to NPAC.
Beth Watkins, AT&T, agreed to provide text for this requirement
including how it would be tested and measured.

REPORT TO NANC
* Core requirements have been identified
* Requirements development is expected to be completed in October
* Broadcast failures rate is not improving [2.7% for June]

NEXT MEETING

The next slow horse meeting will be held Tuesday morning, 9-14-99,
at Chicago, immediately prior to the LNPA-WG meeting starting that
afternoon.
Tentative agenda the September 14th LNPA-WG's Slow Horse subcommittee
meeting is as follows:

* Review text provided by John and Beth
* Discuss root cause analysis of end-to-end process as it contributes
    to slow horse, etc. problem
* Propose SOA requirements (such as for notification-receipt volumes)
* Establish values to use for each proposed requirement
* Determine how/where to measure adherence to each requirement
* Determine how to test each requirement