PI80691: WITH WINDOW SCALING, THE TCP SEND WINDOW (WINDOW SIZE) IS SET TOZERO IF THE FREE BUFFER SPACE IS LESS THEN THE SCALING FACTOR

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The TCP send send window (TCP header window size) can be set to
  zero even though there is a small amount of TCP receive buffer
  space available. This can occur when tcp window scaling is being
  used to allow send windows to grow larger than the 64K value.
  When a small amount of TCP receive buffer space remains, the
  scaling algorithm causes the caluculated window to be sent as
  zero. This causes the remote host to stop sending any further
  data until the window increases. This is particularily critical
  for applications, like FTP, that use msgwaitall and wait until a
  specific amount of data is accumulated in the TCP receive buffer
  before it's read completes.
  

Local fix

• For applications using msgwaitall, like FTP insure that the
  TCPCONFIG TCPMAXRCVBufrsize is set to atleast 512K
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of the IBM Communications Server for z/OS Version  *
  * 2 Releases 2, and 3 IP                                       *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * TCP window scaling may cause applications issuing receive    *
  * operations with msg_waitall to stall.                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The TCP receive buffer size for a connection is initialized to
  the TCPCONFIG TCPRCVBUFRSIZE value.  The application can alter
  the buffer size by issuing a setsockopt() for SO_RCVBUF with a
  value up to a maximum of the TCPCONFIG TCPMAXRCVBUFRSIZE value.
  When the receive buffer size is 64K or larger the connection
  will attempt to use window scaling in order to advertise a
  receive window larger than 64K.  The scaling factor used by z/OS
  will be 5 when the receive buffer is 64K or larger as long as
  the peer supports window scaling.  The receive window size is
  calculated as 2 times the receive buffer size (not to exceed the
  TCPMAXRCVBUFRSIZE) minus the amount of data in the receive
  buffer.  When window scaling is active on the connection the
  receive window is shifted by the scaling factor which causes the
  least significant bytes to be shifted out.  The receive window
  advertised in the TCP header will be zero when the receive
  window is 31 bytes or less and the scaling factor is 5.  This
  has no measurable impact on TCP connection throughput as long as
  the application reads the data from the receive buffer.  The
  problem arises when the application issues a read operation with
  the msg_waitall flag and a read size greater than the
  TCPRECVBUFRSIZE minus 32.  The msg_waitall causes the read
  operation to wait until the entire read size is available in the
  receive buffer.  As the data arrives it is possible for the
  advertised window to become zero when there are 31 bytes or
  less, thus preventing the peer from sending new data to fill the
  buffer.  The peer will send window probes with 1 new byte of
  data and eventually fill the receive buffer, thus allowing the
  msg_waitall read operation to complete.  This probing activity
  to fill the receive buffer will significantly impact the
  throughput on the connection.  To prevent this problem the
  TCPCONFIG TCPMAXRCVBUFRSIZE should be set to the maximum
  msg_waitall read operation size plus 31.  To improve throughput
  it is recommended the TCPMAXRCVBUFRSIZE be set to 2 times the
  largest msg_waitall read operation size.
  FTP uses the msg_waitall flag with a read size of 180K.
  Configuring or allowing the default TCPMAXRCVBUFRSIZE of 256K or
  larger will prevent FTP from stalling while the sender fills the
  receive buffer with probe data.
  FTP is one of the z/OS applications that uses the msg_waitall
  flag.
  

Problem conclusion

• EZBTCFRD has been amended to dynamically increase the receive
  buffer size to the read size when the msg_waitall flag is
  specified, up to the TCPMAXRCVBUFRSIZE + 31 to allow for the
  bytes potentially shifted from the advertised receive window.
  

Temporary fix

Comments

APAR Information

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

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

  UI53410 UI53411

Modules/Macros

• EZBTCFRD
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R230 PSY UI53411

     UP18/03/28 P F803

• R220 PSY UI53410

     UP18/03/28 P F803

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.