Performance considerations for APPN and HPR

The following can affect the performance of the APPN and HPR protocols:

• Transmission priority

  When you create a class-of-service description, you can define one of three transmission priorities for each class of service. You can specify, using the transmission priority (TMSPTY) parameter, that the transmission priority for any class of service is high, medium, or low.

  The transmission priority you specify is carried in the session activation request at session establishment. The transmission priority allows each logical unit on the session and each routing entry along the session path to store the same transmission priority. By assigning an appropriate mode (which includes a class of service) at session activation time, you can ensure a better response time for the applications that require it. Generally, interactive traffic should have a high priority and batch traffic a low priority.

• Route addition resistance

  Route addition resistance (RAR) is a relative value that indicates how desirable one network node is, as compared to other network nodes, for having intermediate sessions routed through it.

  Changing this value and working with the different class-of-service descriptions can control route sessions.

  The RAR value is defined in the network attributes for the local iSeries system.

• Pacing values: See Pacing (INPACING, OUTPACING, MAXINPACING) parameters for pacing considerations.

• Session activation considerations

  When a session is requested to a remote location that matches a network node control-point name, a directory search is not performed by the node that calculates the route. This is true if the session request is being started by a user on the network node, or on an end node that the network node is providing services for. Session start requests for remote locations in end nodes and remote locations in network nodes that do not match the control-point name of the network nodes take longer. These session start requests take longer because the directory search needs to be sent and the replies need to be received.

• Maximum intermediate sessions

  The Change Network Attributes (CHGNETA) command specifies the maximum number of intermediate sessions that are allowed on a network node. When the number of intermediate sessions reaches 90% of the maximum value, the node is marked as congested. A node that is congested may or may not be used for intermediate sessions that depend on the class-of-service definition. The node is not congested when the number of intermediate sessions drops below 80% of the configured value. Also, if the maximum number of intermediate sessions is reached (100%), then intermediate sessions will not be allowed through this network node until the value drops. You can limit the effect of intermediate sessions on local processing by setting an appropriate value.

• Segmentation and reassembly

  On iSeries™, some IOPs that support the local area network protocols, such as token ring and Ethernet, have the ability to perform segmentation and reassembly of SNA Request Units. Performing this function in the IOPs offloads this work from the server CPU. The server CPU is free to perform other tasks.

  Communications input/output adapters (IOAs), such as Gigabit Ethernet, do not require an input/output processor (IOP) and therefore perform segmentation in the server CPU. Gigabit Ethernet adapters do not automatically support SNA. Enterprise Extender (or AnyNet®) is required to allow SNA data to flow over a Gigabit adapter. IBM® recommends that Enterprise Extender be used in place of AnyNet.

  With APPN, any network congestion control is handled on a hop-by-hop basis by using pacing values. It is possible to over-drive connections in an APPN environment. A particular system might receive more data over a communications link than it can handle based on buffer space. The system requires the node that sends the data to retransmit all of the frames that were sent following the last successfully acknowledged frame. This retransmission occurs at the data link control (DLC) layer.

  HPR has little IOP assistance. Much of the segmentation and reassembly is done in the server CPU.

• Error recovery

  APPN requires link-level error recovery to cause retransmission of lost frames. This link-level error recovery can only survive short and temporary outages (several seconds). If a link outage or node outage occurs, that is of longer duration, APPN has no recovery mechanisms for keeping the affected sessions active. The applications must handle any session recovery.

  The following matrix shows how HPR traffic is supported between two systems that are based on their HPR link-level error recovery settings. The HPR link-level error settings are exchanged between the systems:

  System 1	System 2
  	No link-level ERP allowed	Link-level ERP required	Prefer no link-level ERP but might run using link-level ERP
  No link-level ERP allowed	HPR supported (no ERP)	HPR not used	HPR supported (no ERP)
  Link-level ERP required	HPR not used	HPR supported (uses ERP)	HPR supported (uses ERP)
  Prefer no link-level ERP but might run using link-level ERP	HPR supported (no ERP)	HPR supported (uses ERP)	HPR supported (no ERP)

For information about high-performance routing, see Optimize communications using high-performance routing.