rfc2562.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,449 行 · 第 1/5 页

       -   TotalRts (sum of the total response times for all
           transactions in the period)

       -   TotalIpRts (sum of the IP network transit times for all
           transactions in the period; note that if IP network transit
           times are being excluded from the response time collection,
           this value will always be 0).

   o   Also maintain sliding counters, initialized to zero, for each of
       the quantities being counted:

       -   AvgCountTrans (sliding count of transactions)
       -   TotalRtsSliding (sliding count of total response times)
       -   TotalIpRtsSliding (sliding count of IP network transit times)

   o   At the end of each sample period, update the sliding interval
       counters, using the following floating-point calculations:

             AvgCountTrans = AvgCountTrans + T
                  - (AvgCountTrans / SPMult)

             TotalRtsSliding = TotalRtsSliding + TotalRts
                  - (TotalRtsSliding / SPMult)



White & Moore               Standards Track                    [Page 16]

RFC 2562                     TN3270E-RT-MIB                   April 1999


             TotalIpRtsSliding = TotalIpRtsSliding + TotalIpRts
                  - (TotalIpRtsSliding / SPMult)

       Then reset T, TotalRts, and TotalIpRts to zero for use during the
       next sample period.

   o   At the end of a collection interval, update the following MIB
       objects as indicated; the floating-point numbers are rounded
       rather than truncated.

        tn3270eRtDataAvgCountTrans = AvgCountTrans
        tn3270eRtDataAvgRt = TotalRtsSliding / AvgCountTrans
        tn3270eRtDataAvgIpRt = TotalIpRtsSliding / AvgCountTrans

       As expected, if IP network transit times are being excluded from
       response time collection, then tn3270eRtDataAvgIpRt will always
       return 0.

   The sliding transaction counter AvgCountTrans is not used for
   updating the MIB object tn3270eRtDataCountTrans:  this object is an
   ordinary SMI Counter32, which maintains a total count of transactions
   since its last discontinuity event.  The sliding counters are used
   only for calculating averages.

   Two mechanisms are present in the MIB to inhibit the generation of an
   excessive number of notifications related to average response times.
   First, there are high and low thresholds for average response times.
   A tn3270eRtExceeded notification is generated the first time a
   statistically significant average response time is found to have
   exceeded the high threshold.  (The test for statistical significance
   is described below.)  After this, no other tn3270eRtExceeded
   notifications are generated until an average response time is found
   to have fallen below the low threshold.

   The other mechanism to limit notifications is the significance test
   for a high average response time.  Intuitively, the significance of
   an average is directly related to the number of samples that go into
   it; so we might be inclined to use a rule such as "for the purpose of
   generating tn3270eRtExceeded notifications, ignore average response
   times based on fewer than 20 transactions in the sample period."

   In the case of response times, however, the number of transactions
   sampled in a fixed sampling period is tied to these transactions'
   response times.  A few transactions with long response times can
   guarantee that there will not be many transactions in a sample,
   because these transactions "use up" the sampling time.  Yet this case





White & Moore               Standards Track                    [Page 17]

RFC 2562                     TN3270E-RT-MIB                   April 1999


   of a few transactions with very poor response times should obviously
   be classified as a problem, not as a statistical anomaly based on too
   small a sample.

   The solution is to make the significance level for a sample a
   function of the average response time.  A value IdleCount is
   specified, which is used to qualify an sample as statistically
   significant.  In order to determine at a collection interval whether
   to generate a tn3270eRtExceeded notification, a TN3270E server uses
   the following algorithm:

      if AvgCountTrans * ((AvgRt/ThreshHigh - 1) ** 2) >=  IdleCount
      then generate the notification,

   where AvgRt is the value that would be returned by the object
   tn3270eRtDataAvgRt at the end of the interval, and the "**" notation
   indicates exponientiation.

   Two examples illustrate how this algorithm works.  Suppose that
   IdleCount has been set to 20 transactions, and the high threshold to
   200 msecs per transaction.  If the average observed response time is
   300 msecs, then a notification will be generated only if
   AvgCountTrans >= 80.  If, however, the observed response time is 500
   msecs, then a notification is generated if AvgCountTrans >= 9.

   There is no corresponding significance test for the tn3270eRtOkay
   notification:  this notification is generated based on an average
   response time that falls below the low threshold, regardless of the
   sample size behind that average.

3.5.2  Response Time Buckets

   The MIB also supports collection of response time data into a set of
   five buckets. This data is suitable either for verification of
   service level agreements, or for monitoring by a management
   application to identify performance problems.  The buckets provide
   counts of transactions whose total response times fall into a set of
   specified ranges.

   Like everything for a collection, the "total" response times
   collected in the buckets are governed by the specification of whether
   IP network transit times are to be included in the totals.  Depending
   on how this option is specified, the response times being counted in
   the buckets will either be total response times (F - D), or only SNA
   network transit times (effectively E - D, because when it is
   excluding the IP-network component of transactions, a server makes
   timestamp F identical to timestamp E).




White & Moore               Standards Track                    [Page 18]

RFC 2562                     TN3270E-RT-MIB                   April 1999


   Four bucket boundaries are specified for a response time collection,
   resulting in five buckets.  The first response time bucket counts
   those transactions whose total response times were less than or equal
   to Boundary 1, the second bucket counts those whose response times
   were greater than Boundary 1 but less than or equal to Boundary 2,
   and so on.  The fifth bucket is unbounded on the top, counting all
   transactions whose response times were greater than Boundary 4.

   The four bucket boundaries have default values of:  1 second, 2
   seconds, 5 seconds, and 10 seconds, respectively.  These values are
   the defaults in the 3174 controller's implementation of the SNA/MS
   RTM function, and are thought to be appropriate for this MIB as well.

   In SNA/MS the counter buckets were (by today's standards) relatively
   small, with a maximum value of 65,535.  The bucket objects in the MIB
   are all Counter32's.

   The following figure represents the buckets pictorially:

            ----------------------------------------------
            |                                            |
            |          Response Time Boundaries          |
            | |       |       |       |       |       |  |
            | |       |       |       |       |       |  |
            | |       |       |       |       |      no  |
            | 0      B-1     B-2     B-3     B-4    bound|
            | |       |       |       |       |       |  |
            | |Bucket1|Bucket2|Bucket3|Bucket4|Bucket5|  |
            | -----------------------------------------  |
            |                                            |
            ----------------------------------------------

4.0  Structure of the MIB

   The TN3270E-RT-MIB has the following components:

   o   tn3270eRtCollCtlTable
   o   tn3270eRtDataTable
   o   Notifications
   o   Advisory Spin Lock Usage

4.1  tn3270eRtCollCtlTable

   The tn3270eRtCollCtlTable is indexed by tn3270eSrvrConfIndex and
   tn3270eClientGroupName imported from the TN3270E-MIB.
   tn3270eSrvrConfIndex identifies within a host a particular TN3270E





White & Moore               Standards Track                    [Page 19]

RFC 2562                     TN3270E-RT-MIB                   April 1999


   server.  tn3270eClientGroupName identifies a collection of IP clients
   for which response time data is to be collected.  The set of clients
   is defined using the tn3270eClientGroupTable from the TN3270E-MIB.

   A tn3270eRtCollCtlEntry contains the following objects:

                --------------------------------------------------
      1st Index | tn3270eSrvrConfIndex             Unsigned32    |
      2nd Index | tn3270eClientGroupName           Utf8String    |
                | tn3270eRtCollCtlType             BITS          |
                | tn3270eRtCollCtlSPeriod          Unsigned32    |
                | tn3270eRtCollCtlSPMult           Unsigned32    |
                | tn3270eRtCollCtlThreshHigh       Unsigned32    |
                | tn3270eRtCollCtlThreshLow        Unsigned32    |
                | tn3270eRtCollCtlIdleCount        Unsigned32    |
                | tn3270eRtCollCtlBucketBndry1     Unsigned32    |
                | tn3270eRtCollCtlBucketBndry2     Unsigned32    |
                | tn3270eRtCollCtlBucketBndry3     Unsigned32    |
                | tn3270eRtCollCtlBucketBndry4     Unsigned32    |
                | tn3270eRtCollCtlRowStatus        RowStatus     |
                --------------------------------------------------

   The tn3270eRtCollCtlType object controls the type(s) of response time
   collection that occur, the granularity of the collection, whether
   dynamic definite responses SHOULD be initiated, and whether
   notifications SHOULD be generated.  This object is of BITS SYNTAX,
   and thus allows selection of multiple options.

   The BITS in the tn3270eRtCollCtlType object have the following
   meanings:

   o   aggregate(0) - If this bit is set to 1, then data SHOULD be
       aggregated for the whole client group.  In this case there will
       be only one row created for the collection in the
       tn3270eRtDataTable.  The first two indexes for this row,
       tn3270eSrvrConfIndex and tn3270eClientGroupName, will have the
       same values as the indexes for the corresponding
       tn3270eRtCollCtlEntry.  The third and fourth indexes of an
       aggregated tn3270eRtDataEntry have the values unknown(0)
       (tn3270eRtDataClientAddrType) and a zero-length octet string
       (tn3270eRtDataClientAddress).  The fifth index,
       tn3270eRtDataClientPort, has the value 0.

       If this bit is set to 0, then a separate entry is created in the
       tn3270eRtDataTable from each member of the client group.  In this
       case tn3270eRtDataClientAddress contains the client's actual IP





White & Moore               Standards Track                    [Page 20]

RFC 2562                     TN3270E-RT-MIB                   April 1999


       Address, tn3270eRtDataClientAddrType indicates the address type,
       and tn3270eRtDataClientPort contains the number of the port the
       client is using for its TN3270/TN3270E session.

   o   excludeIpComponent(1) - If this bit is set to 1, then the server
       SHOULD exclude the IP-network component from all the response
       times for this collection.  If the target SNA application
       specifies DR in any of its replies, this DR will still be passed
       down to the client, and the client's response will still be
       forwarded to the application.  But this response will play no
       role in the server's response time calculations.

       If this bit is set to 0, then the server includes in the
       collection only those transactions for which it can include an
       (approximate) IP-network component in the total response time for
       the transaction.  This component MAY be derived from a "natural"
       DR (if the client supports the RESPONSES function), from a
       dynamic DR introduced by the server (if the client supports the
       RESPONSES function and the ddr(2) bit has been set to 1), or from
       TIMING-MARK processing (if the client supports TIMING-MARKs).

       If this bit is set to 1, then the ddr(2) bit is ignored, since
       there is no reason for the server to request additional responses
       from the client(s) in the group.

   o   ddr(2) - If this bit is set to 1, then the server SHOULD, for
       those clients in the group that support the RESPONSES function,
       add a DR request to the FIC reply in each transaction, and use
       the client's subsequent response for calculating an (approximate)
       IP-network component to include in the transaction's total
       response times.

       If this bit is set to 0, then the server does not add a DR
       request that it was not otherwise going to add to any replies