Subject: Response to Derek's comments on the TN3270E-RT MIB

From: Robert Moore <[email-masked]>
Date: Fri, 8 May 1998 14:58:30 -0400

Michael & Derek,

Let me take a pass through Derek's comments on the RT MIB, since
most of them can be handled very quickly.  I'll take them in the
order they appear in Michael's note, identifying them as
DB-RT-1 through DB-RT-13.  (If you have Michael's earlier note
with Derek's comments, you'll need to go through the document
and number the "@DB"'s.  I know this is a bit of a pain, but we
need to be able to refer to each of Derek's comments
unambiguously.)

DB-RT-1:  How about the following, which makes the fix in an
          architecturally clearer way:  "...either an SNA type
          2.0 node, a boundary-function-attached type 2.1 node,
          or an APPN node acting in the role of a Dependent LU
          Requester (DLUR)"?  There is no architecture
          category called "PU Type 2 node," and an APPN node
          that's not boundary-function-attached can't be a
          TN3270E server unless it's also a DLUR.

DB-RT-2:  Use of UNBINDs in RT calculations.  Not sure why your
          comment is placed where it is, but the point is valid:
          transactions where the host sends an UNBIND are
          special.  The simplest thing to do is to say that
          these transactions are not used in RT calculations.

          I'll add the following paragraph after the fifth
          paragraph of section 3.2:

             Because it is a special case, a transaction in
             which a target SNA host returns an UNBIND in
             response to a client's request, and the TN3270E
             server forwards the UNBIND to the client, is not
             included in any response time calculations.

DB-RT-3:  Don't understand the comment.  What is not necessarily
          true?  What wording are you asking us to change?

DB-RT-4:  Sounds reasonable; I'll make this change.

DB-RT-5:  You're correct in saying that the server must request
          the response when it forwards the FIC RU to the client,
          not when it forwards the LIC RU.  There are a number of
          places where I need to change the document to reflect
          this.

          I agree that timestamp E is taken at some point during
          the server's processing of the LIC RU.  But I'm not
          sure we want to constrain servers to timestamping on
          their "SNA edge", as your wording suggests, rather
          than on their "Telnet edge" (or somewhere in between).
          Since F-E yields an IP network time, my preference
          would be to say that the server SHOULD (not "SHALL")
          take timestamp E as close to its "Telnet edge" as
          possible.

DB-RT-6:  You need to say more here.  What are the "two
          separate transactions" for which you're suggesting
          that the server capture response times?

DB-RT-7:  Right.  This is the same issue as DB-RT-5.  For the
          figure right above this comment, I'm going to remove
          the +/- RSP right below the FIC RU's line, and I'm
          going to remove the "(DR)" from the reply triggered
          by the LIC RU.  Is this all I need to do to address
          this comment?

DB-RT-8:  This whole paragraph goes away, because there is no
          "earlier one" for the server to use.

DB-RT-9:  Agree to the change -- can we have the exact
          replacement text?

DB-RT-10:  OK (typo:  "<"-->">="); also update object name in
           the MIB module:  "tn3270eRtCollCtlIdleRate"-->
           "tn3270eRtCollCtlIdleCount".

DB-RT-11:  More of the FIC / LIC fix.  How about this text?

              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...

DB-RT-12:  I think "actual" is better here; "cumulative" opens
           up issues of SMI "counter theory" that we don't need
           to open.  The contrast is between a Gauge32 object
           and a Counter32.

DB-RT-13:  OK (typo:  "keep"-->"kept")

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: "Derek W. Bolton" <[email-masked]>
Date: Sun, 10 May 1998 09:45:13 +1000 (EST)

Bob,

>           TN3270E server unless it's also a DLUR.

The BF-attached 2.1 node is OK.  I still don't get the second part.
It could be a 2.0 or 2.1 node attached through a DLUR.  It makes no
odds whether the DLUR is in the same lump of code or a separate node.
Since the DLUR-DLUS pair provides the BF, the whole thing reduces to
"2.0 or 2.1 attached through a BF."  But since your proposed rewording
at least admits the CIP server, I'll settle for that ;-).

>              included in any response time calculations.

OK.

>           true?  What wording are you asking us to change?

I meant that the value added is not only, and maybe not even
principally, that claimed.  There is also value in measuring the
server<->Host times.

>           take timestamp E as close to its "Telnet edge" as

OK.

>           that the server capture response times?

I'm saying that even if the Host only sends CD, that still requires
the server to send a Write and WCC to the client (otherwise the
keyboard stays locked).  So why treat this any differently from a
normal end of transaction?  As far as the 3270 appl is concerned,
there is no difference between sending null RU CD and sending the
two-byte message write+WCC(restore), CD.  So the server should not
account them differently.  If the client then sends in more data
and the Host at last gives a textual reply, that is a separate
transaction.

>           by the LIC RU.  Is this all I need to do to address

Yes.

> DB-RT-9:  Agree to the change -- can we have the exact

"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 proposed here, it has a half-life of
SPMult*SPeriod."

>               to the FIC reply in each transaction, and use...

OK.

>            to open.  The contrast is between a Gauge32 object

I understand your point, but my concern is that both counts are
actual - they just measure from different start times.

Regards,
  Derek