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

From: [email-masked]
Date: Mon, 01 Jun 1998 09:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the Telnet TN3270
Enhancements Working Group of the IETF.

	Title		: TN3270E Service Location and Session Balancing
	Author(s)	: K. Kasthurirangan, G. Ledford, J. Naugle
	Filename	: draft-ietf-tn3270e-service-loc-01.txt
	Pages		: 14
	Date		: 29-May-98
	
This document discusses the implementation of Service Location Protocol
and session balancing with a TN3270E emulator in a client server
implementation with a TN3270E server.

Application program developer's can locate TN3270E services and load
balance among those services (3270 host sessions), by using this
Service Location Protocol support.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tn3270e-service-loc-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tn3270e-service-loc-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-tn3270e-service-loc-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jim Naugle <[email-masked]>
Date: Tue, 2 Jun 1998 21:46:47 -0400

Thanks for your comments again, this is good, even though it causes me
more work.  Thanks
==========
All-
    Attached is a copy of the above draft with comments interspersed.
I started each comment line with "<<".  I will cover some of my points
here but I have more mostly grammer and typo comments in the attached.

----------------------------------------------------------------------
In section 4.1 on Server load:

   An application could issue a  SL_GetService request [2] to locate a
   TN3270E server. Then an application designed to perform least-load
   location of  a TN3270E service, could issue a series of SL_GetAttrs
   calls [2] directed to each URL to obtain the load measurement of
   each server.
<< The SG_GetAttrs call is issued to get information about each URL... it
<< is not "directed to" the URL.  The URL (in both the SA and DA scenario) is
<< not the one that will responding... the SA and DA will.  So perhaps
<< ".. could issue a series of SL_GetAttrs calls [2] to obtain the load
<< measurement of each server specified with a URL."
-----------------------------------------------------------------------
In 7.1, the overview of client implementation:

<<Are you interested in having the user able to configure:
<<    Max Path MTU
<<    Scoped Services Only
<<    Broadcast vs Multicast
<<    Multicast Radius
<<    A specific DA address or not to try DAs at all?
-----------------------------------------------------------------------
In section 8, Sample Trace Flow of SLP and Session Balancing

   SLP: SL_GetService Reply: service:tn3270://206.109.45.140:1366,
   LOAD = 26
<< The above examples do not have the normal TN3270E port.  I recommend
<< that the examples be changed to have port 23.
-----------------------------------------------------------------------
In section 9.  Service Registration Messages and Service Templates

   Server Service Template
<< I still object to the commserver inclusion in this document.   A TN3270E
<< Client will NOT be searching for the commserver URL.  All discussion so far
<< in this document has been about TN3270E specifically.  If you want to change
<< the scope of this document to include this or to make it more generic, then
<< you have a lot more work to do...
<< 1) Change the title
<< 2) Everywhere else in this document where you refer to a TN3270E server you
<< should also refer to commserver or just refer to a "server" not a TN3270E
<< server or a commserver.
<< 3) discussion of when the SLP exchanges happen in relation to the commserver
<< connection negotiations.
<< 4) etc.
<< At the very least you should put an introductory paragraph explaining why
<< this commserver information is in this TN3270E document (and that any one
<< implementing TN3270E should ignore this information).  Also the TN3270E
<< templates and Registation Messages should appear first in these sections.
<<
<< I think these sections could use a bit more sub-dividing.  It is not obvious
<< where Server Service Templates ends and Server Service Registration Message
<< begins so how about:
<< 9.  Service Registration Messages and Service Templates
<< 9.1   Server Service Template
<< 9.1.1 TN3270E Template
<< 9.1.2 Commserver Template
<< 9.2   Server Service Registration Message
<< 9.2.1 TN3270E Message
<< 9.2.2 Commserver Message
<<
<< On a different topic... Is there a way to indicate which of the fields in
<< the template are required and which are optional.  For example if BIND, DATA
<< and RESPONSES are required then why do they have to exist in the template...
<< they would be implied by the fact that the service: URL is TN3270E.  Do all
<< SLP TN3270E server have to implememt Platform, Release, ServerName, Load?
<< What are the consequences if they don't?

Jim Naugle
Client/Server SNA API Development
Developer Support for ISVs
Internet: [email-masked]
Tel. 919-254-8789
Fax. 919-254-5295

---

From: Rose Marie Carissimi <[email-masked]>
Date: Wed, 3 Jun 1998 14:21:42 -0400

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 thatthe value can be
compared.

---

From: "Derek W. Bolton" <[email-masked]>
Date: Tue, 9 Jun 1998 11:29:37 +1000 (EST)

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: Deric Villanueva <[email-masked]>
Date: Wed, 10 Jun 1998 10:26:02 -0700

> -----Original Message-----
> From: Derek W. Bolton [SMTP:[email-masked]]
> Sent: Tuesday, June 09, 1998 5:23 PM
> To:   [email-masked]
> Cc:   [email-masked]; [email-masked]
> Subject:      Re: I-D ACTION:draft-ietf-tn3270e-service-loc-01.txt
>
> > 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?
>
> 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.
>
>  I see the dilemna now.  I believe the rt-mib definition for
> transaction is a fair measure, and directly applicable to our purpose.
>
> > 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.
>
> You are right it is out of our scope to directly track loads from
> other services.  I had thought that if the "transaction" statistic
> used packets or bytes /sec then it could be used as a counter balance
> indicator for a server with few logged on clients but who has clients
> doing IND$FILE transfers or some other high volume type transactions.
> AND if it was a raw count of bytes or packets (as opposed to just
> 3270/5250 traffic) it would potentially indirectly indicate another
> service (except on multihomed devices) being used on the machine.
> Sounds like the "incremental impact" stat will do this.
>
> > 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.
>
>  I agree with your points about the network and oversubsciption etc.,
> however I think that for the purposes of srvloc a load_metric
> statement from the service agent is more efficient than a load of
> statistics that must be calculated to a load_metric by the user agent
> or end client in order to determine connectibilty.  It may/should be
> that the actual TN3270 Server does none of the calculations and the
> service agent does it all.  I unfortunately did not keep up with the
> mib work but isn't much of the necessay stats there?
>
>
>  > 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.
>
> Ah yes, flexibility -vs- conformity
>
> > cheers Deric <<= The right spelling :-)
>
> Regards,
>   Derek (deliberately misspelt to avoid confusion)
>
>   Deric
> > > -----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,
> >