Print this page Print NPIF » NANC Change Orders » NANC 362

NANC 362

Vendor Metrics

Origination Date :01/01/2002

Originator:LNPA-WG

Description:

Business Need:

 

SOA/LSMS vendors request that NPAC volume metrics be captured that would allow SOA/LSMS vendors to create a model for LNP transactional performance based on actual porting data to the SOA and LSMS.

 

Once a model is developed, the intent is to continue to capture various porting data (nominal, peak, duration at peak) to determine the validity of the model.

 

Once the model has been validated and accepted, SOA/LSMS vendors will use this model to intelligently establish the current performance requirements, and by extrapolation, the future requirements.

As porting volumes increase, the business need for this change order becomes more time sensitive to help with the situation where porting is delayed because of a slow horse situation.

Final Resolution:

Pure Backwards Compatible:  YES

 

Both SOA and LSMS data should be gathered.

 

An extract is shown below from the Minutes from the Vendor Metrics Call, May 2, 2002, version 1.2.  Refer to the Vendor Call Minutes for full details.

 

Discussion of the LSMS metrics we should gather.

 

The group proposed monthly reports showing message traffic mix.

 

Items to be gathered are:

  1. TN range size (including range of 1),
  2. Message type (create, modify, delete, queries, etc),
  3. Number of messages of this range size and type,
  4. aggregated in 15-minute intervals,
  5. whether transmission congestion occurred during the period,
  6. if congestion occurred, start and end times of congestion,
  7. whether an abort occurred i.e. downstream did not respond during the period.

It was agreed that at this time the following report would be a sufficient starting place.

 

For each 15 minute interval,

  • For the category of prepared messages, report
    1. Message type,
    2. Range size,
    3. and the number of messages with that range size and message type,
  • For the category of transmitted messages, for the best case reportMessage type,
    1. Range size,
    2. The number of messages with that range size and message type,
    3. Count of number of times entered into congestion,
    4. List of congestion intervals,
    5. Count of aborts,
    6. and count of aborts due to timeout.

Discussion of SOA metrics proposed by the Slow Horse subcommittee in August and September of 2000.

 

We discussed SOA metrics and agreed that what kind of data that the Slow Horse had proposed was still valid.  It was agreed that the sampling interval should be 15-minute intervals and that the LTI information was not relevant.  Furthermore, the data should be reported for both the prepared messages and the transmitted messages as was specified above for the LSMS.  Consequently, for the SOA the report needs to contain:

  1. All NPAC notifications to SOA.
  2. All SOA requests to NPAC.

This information should be reported in 15-minute intervals and categorized as specified above for LSMS messages. For messages sent to the NPAC, they should be reported as:

  1. TN range size (including range of 1),
  2. Message type (create, modify, delete, queries, etc).,
  3. Number of messages of this range size and type,
  4. aggregated in 15-minute intervals.

June ’02 LNPAWG, additional discussion.

 

The desire is to obtain the offered load, versus what the NPAC is actually producing.  In other words, the request versus the result of the request.

 

Colleen Collard would like lots of data on both the inbound and outbound traffic, but realize that the more data that is requested, the longer and more expensive to produce that data.  So, initially the group can accept what the NPAC is sending down to the LSMS.

 

Jim Rooks – porting business need is driving SOA, which drives NPAC, which drives LSMS.

 

John Malyar – problem is porting that happens at any single point in time.

 

Jim Rooks – we really need to smooth out data.  We are currently looking at request data, the report is sent to NAPM.

 

Steve Addicks – the past doesn’t necessarily reflect future needs/load with wireless (mostly single ports), and also pooling.

 

Dave Garner – need to know what we have today, and also need to do a forecast/projection for the future.

 

NeuStar action item:  provide a list of metrics for a baseline of data elements as the NPAC’s side of the projected load, as to what is occurring today.  Jim Rooks provided this information at the Aug ’02 LNPAWG meeting.

Jan 06 – ESI discussed internally.  Performance on both sides has been resolved.  Agreed to move to Cancel-Pending.

3/06 – Deleted after March LNPAWG meeting.

Related Release:

N/A

Status: Closed