IBM Support

PM44234: DELAY IN LU ASSIGNMENT FOR A LUNR BECAUSE OF NAGLE ALGORITHM DELAYING DATA TRANSMISSION

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A Telnet is configured with shared LUs, so it is acting as a
    LUNR.  Another Telnet running on a different TCPIP stack is
    acting as a LUNS.  When the LUNR and LUNS are communicating, the
    Nagle algorithm is preventing small packets from being sent
    individually.  This can slow down the assignment of LUs as the
    data will not be sent until the delayACK timer expires, which
    can be 200ms.  This delay can grow to over 30 seconds in
    configuration with a large number of LUGroups mapped to a
    connection and the client includes a LU group name when
    establishing the connection.  The Telnet client will see a delay
    before being presented with the MSG10 screen.
    
    VERIFICATION STEPS:
    1) Slow response time for LU requests from LUNR system on
    different TCPIP stacks than the LUNS.  The delay may grow to be
    over 30 seconds.
    2) LU requests from a LUNR on the same TCPIP stack as the LUNS
    are not delayed
    3) A packet trace of the connection between the LUNR and LUNS
    will show delayed acks or data being sent after a 200ms gap on
    the connection.
    

Local fix

  • Coding NoDelayAck on the PORT reservation for the Telnet
    LUNS port and on the TCPCONFIG statement can reduce the delay
    some.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release(s)  10, 11, 12,   *
    *                 and 13 IP: Telnet facilities using the       *
    *                 Telnet LU Name Server ( LUNS ) and LU Name   *
    *                 Requestor ( LUNR ).                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: Slow performance in LU assignment       *
    *                      from LUNS server due to Nagle           *
    *                      algorithm.                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem may be summarized as follows:
    
    1. A Telnet LUNR running on one TCPIP stack established
       a connection to a Telnet LUNS server running on a
       different TCPIP stack.
    
    2. The Telnet LUNR was configured with a large number
       of shared LU groups containing a single LU such as
       in the following example:
    
       SLUGROUP    GROUP01
                     TCPM1151
                   ENDSLUGROUP
       LUMAP       GROUP01 ALLIPGROUP SPECIFIC
       SLUGROUP    GROUP02
                     TCPM1152
                   ENDSLUGROUP
       LUMAP       GROUP02 ALLIPGROUP SPECIFIC
    
    3. A TN3270E client connected to the LUNR.  The client was
       configured with a specific LUGROUP name (e.g. GROUP02).
       LUNR handshake processing with the LUNS occurred during
       the connection establishment.  The handshake took an
       excessive amount of time, delaying presentation of the
       USSMSG10 screen at the client.  Packet trace analysis
       revealed that the delay was due to the LUNS/LUNR
       connection being subject to the Nagle algorithm.
    +-------------------------------------------------------------+
    + Please check our Communications Server for OS/390 homepages +
    + for common networking tips and fixes.  The URL for these    +
    + homepages can be found in Informational APAR II11334.       +
    +-------------------------------------------------------------+
    

Problem conclusion

  • Modules EZBTXLUR and EZBTXLUS have been amended to issue a
    SETSOCKOPT specifying the TCP_NODELAY option to disable
    Nagle for the LUNS/LUNR connection.  Macro EZBZTXCF has been
    amended to add an internal serviceability indicator.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM44234

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1B0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-07-21

  • Closed date

    2011-08-09

  • Last modified date

    2011-10-03

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK70617 UK70618 UK70619 UK70620

Modules/Macros

  • EZBTXLUR EZBTXLUS EZBZTXCF
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1A0 PSY UK70617

       UP11/09/20 P F109

  • R1B0 PSY UK70618

       UP11/09/20 P F109

  • R1C0 PSY UK70619

       UP11/09/20 P F109

  • R1D0 PSY UK70620

       UP11/09/20 P F109

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1B0","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1B0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
03 October 2011