rfc2562.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,449 行 · 第 1/5 页
TXT
1,449 行
This section goes into more detail concerning when the various timestamps can be taken as the flows between a TN3270E client and its target SNA host pass through a TN3270E server. In addition, information is provided on how the TN3270 TIMING-MARK request/response flow can be used in place of DR for approximating IP network transit times.White & Moore Standards Track [Page 11] RFC 2562 TN3270E-RT-MIB April 19993.4.1 DR Usage Consider the following flow: ---------------------------------------------------------- | | | Client TN3270E Target SNA | | Server Host | | Timestamps | | | | <---IP Network-------><---SNA Network---> | | | | request D (BB,CD,OIC,ER) | | -------------------------------------------> | | reply(DR) (FIC,ER,EB) | | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply E (LIC,DR) | | <-----------------------------------------< | | | +/-RSP F | | >----------------------------------------> | | | | BB : Begin Bracket ER : Response by exception | | EB : End Bracket DR : Definite Response Requested | | CD : Change Direction FIC : First in chain | | OIC: Only in chain MIC: Middle in chain | | LIC: Last in chain | ---------------------------------------------------------- Timestamp D is taken at the TN3270E server when the server has received data from a client for forwarding to its target SNA host, and the direction of the SNA session allows the server to forward the data immediately (either the direction is inbound towards the SNA host, or the session is between brackets). This is most likely when the server finds the end of record indicator in the TCP data received from the client. The target SNA application returns its reply in one or more SNA Request Units (RUs); in this example there are four RUs in the reply. The first RU is marked as first in chain (FIC), the next two are marked as middle in chain (MIC), and the last is marked as last in chain (LIC). If the SNA host sends a multiple-RU chain, the server does not know until the last RU is received whether DR is being requested. The server's only chance to request DR from the client, however, comes when it forwards the FIC RU, since this is the onlyWhite & Moore Standards Track [Page 12] RFC 2562 TN3270E-RT-MIB April 1999 time that the TN3270E header is included. Since a server may forward the FIC RU to the client before it receives the LIC RU from the SNA host, some servers routinely specify DR on all FIC RUs. If the server has specified DR on the TN3270E request for the FIC RU in a chain, it takes timestamp E when it forwards the LIC RU to the client. Since timestamp E is used for calculating the IP-network time for the transaction, the server SHOULD take timestamp E as close as possible to its "Telnet edge". The server takes timestamp F when it receives the RESPONSES response from the client. A target SNA application doesn't necessarily return data to a client in a transaction; it may, for example, require more data from the client before it can formulate a reply. In this case the application may simply return to the TN3270E server a change of direction indicator. At this point the server must send something to the client (typically a Write operation with a WCC) to unlock the keyboard. If the server specifies DR on the request to the client triggered by its receipt of the change of direction indicator from the SNA application, then timestamps E and F can be taken, and the usual response times can be calculated. When the client sends in the additional data and gets a textual response from the SNA application, the server treats this as a separate transaction from the one involving the change of direction.3.4.2 TIMING-MARK Usage It is possible for a TN3270E server to use the TIMING-MARK flow for approximating IP network transit times. Using TIMING-MARKs would make it possible for a server to collect performance data for TN3270 clients, as well as for TN3270E clients that do not support the RESPONSES function. In order for TIMING-MARKs to be used in this way, a client can't have the NOP option enabled, since responses are needed to the server's TIMING-MARK requests. An IP network transit time approximation using a TIMING-MARK is basically the amount of time it takes for a TN3270 server to receive from a client a response to a TIMING-MARK request. To get an estimate for IP network transit time, a TN3270E server sends a TIMING-MARK request to a client after a LIC RU has been received, as a means of approximating IP network transit time:White & Moore Standards Track [Page 13] RFC 2562 TN3270E-RT-MIB April 1999 --------------------------------------------------- | | | Client TN3270E Target | | Server Host | | Timestamps | | | | <---IP Network-------><---SNA Network---> | | | | request D (BB,CD,OIC,ER) | | -------------------------------------------> | | reply (FIC,ER,EB) | | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply E (LIC,ER) | | <-----------------------------------------< | | TIMING-MARK Rqst E' | | <--------------------- | | | TIMING-MARK Rsp F' | | >-------------------> | | | --------------------------------------------------- The response times can then be calculated as follows: o TN3270E server total response time: (Timestamp E - Timestamp D) + (Timestamp F' - Timestamp E') o TN3270E server IP network time: Timestamp F' - Timestamp E' If a TN3270E server is performing the TIMING-MARK function (independent of the response time monitoring use of the function discussed here), then it most likely has a TIMING-MARK interval for determining when to examine client sessions for sending the TIMING- MARK request. This interval, which is ordinarily a global value for an entire TN3270E server, is represented in the TN3270E-MIB by the tn3270eSrvrConfTmNopInterval object. A TIMING-MARK request is sent only if, when it is examined, a client session is found to have had no activity for a different fixed length of time, represented in the TN3270E-MIB by the tn3270eSrvrConfTmNopInactTime object. Servers that support a large number of client sessions should spread out the TIMING-MARK requests they send to these clients over the activity interval, rather than sending them all in a single burst, since otherwise the network may be flooded with TIMING-MARK requests. When a server uses TIMING-MARKs for approximating response times,White & Moore Standards Track [Page 14] RFC 2562 TN3270E-RT-MIB April 1999 this tends to introduce a natural spreading into its TIMING-MARK requests, since the requests are triggered by the arrival of traffic from an SNA host. A TN3270E server MUST integrate its normal TIMING-MARK processing with its use of TIMING-MARKs for computing response times. In particular, it MUST NOT send a second TIMING-MARK request to a client while waiting for the first to return, since this is ruled out by the TIMING-MARK protocol itself. If a TIMING-MARK flow has just been performed for a client shortly before the LIC RU arrives, the server MAY use the interval from this flow as its approximation for IP network transit time, (in other words, as its (F' - E') value) when calculating its approximation for the transaction's total response time, rather than sending a second TIMING-MARK request so soon after the preceding one. Regardless of when the server sends its TIMING-MARK request, the accuracy of its total response time calculation depends on exactly when the client responds to the TIMING-MARK request.3.5 Performance Data Modelling The following two subsections detail how the TN3270E-RT-MIB models and controls capture of two types of response time data: average response times and response time buckets.3.5.1 Averaging Response Times Average response times play two different roles in the MIB: o They are made available for management applications to retrieve. o They serve as triggers for emitting notifications. Sliding-window averages are used rather than straight interval-based averages, because they are often more meaningful, and because they cause less notification thrashing. Sliding-window average calculation can, if necessary, be disabled, by setting the sample period multiplier, tn3270eRtCollCtlSPMult, to 1, and setting the sample period, tn3270eRtCollCtlSPeriod, to the required collection interval. In order to calculate sliding-window averages, a TN3270E server MUST: o Select a fixed, relatively short, sample period SPeriod; the default value for SPeriod in the MIB is 20 seconds.White & Moore Standards Track [Page 15] RFC 2562 TN3270E-RT-MIB April 1999 o Select an averaging period multiplier SPMult. The actual collection interval will then be SPMult times SPeriod. The default value for SPMult in the MIB is 30, yielding a default collection interval of 10 minutes. Note that the collection interval (SPMult*SPeriod) is always a multiple of the sample period. Clearlly, SPMult*SPeriod should not be thought of as literally the averaging period. The average calculated will include contributions older than that time, and does not weight equally all contributions since that time. In fact, it gives a smoother result than a traditional sliding average, as used in finance. More subtly, it is best to think of the effective averaging period as being 2*SPMult*SPeriod. To see this, consider how long the contribution to the result made by a particular transaction lasts. With a traditional sliding average, it lasts exactly the averaging period. With the aging mechanism described here, it has a half-life of SPMult*SPeriod. o Maintain the following counters to keep track of activity within the current sample period; these are internal counters, not made visible to a management application via the MIB. - T (number of transactions in the period)⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?