Subject: RE: I-D ACTION:draft-ietf-tn3270e-service-loc-01.txt

From: Deric Villanueva <[email-masked]>
Date: Tue, 9 Jun 1998 08:56:01 -0700

Hi Derek
        a) The current transaction rate. << from the note below.

What does this measure? or maybe a better question what metric is used
to measure transaction rate.  Packets/sec? bytesbits/sec?  If I
undersand correctly this statistic could be useful for determining if a
server is also being used to gateway file transfers or even apply to
other shared (from a hardware perspective) functions.

Yes I also agree with you and Rose Marie and I believe that an aggregate
of statistical data is the best way to present equitable load
information from a server perspective.  If every client or agent
requesting service is left to its own devices for determining the
load_metric via some unknown algorithm doesn't that just move the
problem to the client/agent side?  Oh yes, generally the clients will be
relatively vendor homogeneous (but even you must admit that there are
differences between versions) and that if some vendors clients
habitually selects slow servers so be it.  I don't think that is what we
are trying to do though.  There might be some merit in at least
standardizing on REQUIRED versus OPTIONAL statistics and weight of
certain ones over another. That would go a long way in making the
load_metric more deterministic.
cheers
Deric  <<= The right spelling :-)

> -----Original Message-----
> From: Derek W. Bolton [SMTP:[email-masked]]
> Sent: Monday, June 08, 1998 6:30 PM
> To:   [email-masked]
> Subject:      RE: I-D ACTION:draft-ietf-tn3270e-service-loc-01.txt
>
> Rose Marie,
>
> > In the document you state that the individual server load
> > calculation is beyond the scope of the document.  But, if you have
> > multiple TN Servers from different vendors on a single network, if
> > each of the vendors does not use the same load calculation, then how
> > can a TN client actually identify that a specific server is more or
> > less loaded than another.  There must be one calculation that will
> > be used by all servers so that the value can be compared.
>
> I agree completely with your concern.  The suggested configurable
> compensation is unworkable.  It assumes that the difference in the
> algorithms only affects the magnitude of the result, and it puts
> the onus on the customer to fix up the differences.
>
> However, I do not agree that fixing on one algorithm is the solution.
> This is an area where it is not yet clear what constitutes a good
> algorithm.  There will be much to learn from real networks.  It is
> important to leave the door open so that different vendors of servers
> and agents can improve their algorithms piecemeal yet interoperate.
> The opportunity for competitive advantage through superior algorithms
> is good for the industry and good for customers.
>
> One way to achieve this flexibility is to have the servers report a
> set of statistics with well-defined meanings.  The algorithm for
> computing the load resides in the agent that performs the selection.
> The set of statistics needs to be sufficiently broad to permit most
> reasonable algorithms.  It could be structured as a base set plus
> optional extras.
>
> According to my personal view of what the algorithm should be, the
> required set of statistics is:
>
> a) The current transaction rate.
> b) The current number of clients.
> c) The incremental response time impact on each existing client of
>    adding one more similar client.
> d) The current average response time for the clients.
> e) The Host-side component of (d).
> f) Number of available LUs for screens.  (Does any of this apply to
>    printers?)
>
> ((d) and (e) are both needed because the agent may or may not be
> able to determine independently the network transit time between
> the new client and each potential server.  If it can then (e)
> should be used, not (d).)
>
> Armed with the above, the agent can choose the best server - not
> just from the perspective of the new client but from that of the
> entire client set.
>
> (f) is needed because there is a window between retrieving these data
> and making the selection.  So it is advisable to add a bias against
> servers approaching satiety, e.g.: constant/number_available.
>
> Many of these statistics will be provided by the new MIBs being
> proposed: tn3270e-tn3270-mib and tn3270e-rt-mib.
>
> I suggest that (e) and (f) constitute the base set, hotly followed by
> (d), then (a, b, c) as a group.
>
> Regards,
>   Derek

---

From: "Derek W. Bolton" <[email-masked]>
Date: Wed, 10 Jun 1998 10:22:46 +1000 (EST)

> What does this measure? or maybe a better question what metric is
> used to measure transaction rate.  Packets/sec? bytesbits/sec?

Fair question.  It was intended to match the definition of transaction
that will be used for response time measurement in the rt-mib.  That
is, one client message in, plus all the Host reply.  So it does not
count any unsolicited Host output, as may occur with Netstat e.g.

This is the way that we have measured CIP TN3270 server throughput,
since it most closely corresponds with CPU usage.  Of course, there is
some impact from large frames, but our experience is that the largest
frames cost less than twice the CPU of the smallest.  I accept that
this might not be the case for other servers.  Also, it might be a
comms line (either upstream from the server, or common to all clients
of the server) that is the bottleneck, not the CPU.  So it might
be appropriate to report bytes/sec as well.  However, that won't be
enough either, since the agent cannot tell which is the critical
resource.  The server would need to provide its own view of that.
I'll look at this some more.

> If I undersand correctly this statistic could be useful for
> determining if a server is also being used to gateway file transfers
> or even apply to other shared (from a hardware perspective)
> functions.

It is difficult in general to take into account other loads on the
server node.  I wouldn't like to assume a model in which the server
itself is aware of non-tn3270 traffic.  The statistics I listed were
supposed to be purely those concerning the tn3270 server, so it would
not include e.g. FTP transactions.  However, the idea is that these
other impacts could be measured indirectly by the "incremental impact"
statistic.  That is achieved if the server actually measures response
times instead of computing them from the direct loads on the server.

> Yes I also agree with you and Rose Marie and I believe that an
> aggregate of statistical data is the best way to present equitable
> load information from a server perspective.  If every client or
> agent requesting service is left to its own devices for determining
> the load_metric via some unknown algorithm doesn't that just move
> the problem to the client/agent side?

To an extent, but there are significant benefits.

In the short term, it may mean that (different versions of) different
clients make different decisions concerning the optimal server.  But
as long as a substantial proportion make a reasonably accurate choice,
the network as a whole will work well.  You could have half of the
clients making a suboptimal choice, provided that it is not entirely
crazy.  Those servers that are thereby oversubscribed will be avoided
entirely by the remaining clients.  By contrast, if the servers report
a single statistic then you can expect that most agents will make the
same choices.  If there is some subset of servers that understate
their load then they will be oversubscribed.

In the longer term, as I said earlier, it is possible to refine the
algorithm if it is in the clients, or in agents that span servers.
If the algorithm is in the servers then the customer gets locked into
it.  Improving the algorithm in a subset of servers may make the
overall network worse.  Conversely, if a few clients change to
make smarter choices then the overall network improves.

> Oh yes, generally the clients will be relatively vendor homogeneous
> (but even you must admit that there are differences between
> versions) and that if some vendors clients habitually selects slow
> servers so be it.  I don't think that is what we are trying to do
> though.  There might be some merit in at least standardizing on
> REQUIRED versus OPTIONAL statistics and weight of certain ones over
> another. That would go a long way in making the load_metric more
> deterministic.

Yes, there should be required and optional stats.  The optional stats
must carry tags that identify them (rather than being identified by
position) so that new ones can be added in the future.  But I don't
think we can determine the weighting - that must be in the agent
making the selection, maybe configurably.

> cheers Deric <<= The right spelling :-)

Regards,
  Derek (deliberately misspelt to avoid confusion)