IBM Support


A fix is available


You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • Unnecassary retransmission of packets.  Out of order packets can
    trigger FRR processing to retransmit packets.  When the original
    out of order packets arrive an immediate ACK is sent.  This ACK
    can cause the sender to incorrectly assume the retransmitted
    packet was received and filled the gap.  When the retransmitted
    packets arrive the receiver will send an ACK indicating the
    current state of the connection.  If the FRR recovery phase has
    completed and new packets are sent before the ACKs for the
    retransmitted packets arrive these ACKs will appear to be
    duplicate ACKs, triggering FRR to retransmit the new packets.
    As the new packets arrive the resulting ACKs will make the
    sender side progress through the FRR recovery by retransmitting
    what is assumed to be the next missing packet.  When all of the
    original new packets arrive the ACK will cause the sender to
    exit FRR recovery.  When the retransmitted packets arrive they
    will again solicit an immediate ACK with the current state of
    the connection.  If new packets are sent before these ACKs
    arrive they can trigger FRR for the new packets.  This sequence
    of events can continue repeatedly causing unnecarry overhead on
    the network and CPU cycles to process the retransmitted packets.
    With SACK enabled the recovery of multiple packets will
    typically occur sooner and may prevent the problem, however it
    is still possible to see this problem with SACK enabled.
    This problem is most likely to be seen on high latency
    Here is an illustration of the problem assuming a single byte
    of TCP data in each packet.
     -> Data_1
     -> Data_2
     -> Data_3
     -> Data_4
     -> Data_5
                                   -> Data_2  (OOO) <- Ack_1
                                   -> Data_3  (OOO) <- Ack_1
                                   -> Data_4  (OOO) <- Ack_1
                                   -> Data_1        <- Ack_5
                                   -> Data_5        <- Ack_6
                                   -> Data_6        <- Ack_7
     <- Ack_1
     <- Ack_1
     <- Ack_1  -> Data_1  (FRR)
     <- Ack_5  -> Data_5  (FRR)
     <- Ack_6  -> Data_6  (FRR)
     <- Ack_7
     -> Data_7
     -> Data_8
     -> Data_9
                                   -> Data_1  (BW)  <- Ack_7
                                   -> Data_5  (BW)  <- Ack_7
                                   -> Data_6  (BW)  <- Ack_7
                                   -> Data_7        <- Ack_8
                                   -> Data_8        <- Ack_9
                                   -> Data_9        <- Ack_10
     <- Ack_7
     <- Ack_7
     <- Ack_7  -> Data_7  (FRR)
     <- Ack_8  -> Data_8  (FRR)
     <- Ack_9  -> Data_9  (FRR)
     <- Ack_10

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * All users of the IBM Communications Server for z/OS Version  *
    * 2 Releases 3 and 4 IP: TCP SACK                              *
    * PROBLEM DESCRIPTION:                                         *
    * Packets unnecessarily retransmitted on a SACK enabled TCP    *
    * connection.                                                  *
    * RECOMMENDATION:                                              *
    * Apply the PTF                                                *
    Data over a high-latency, SACK enabled, TCP connection arrives
    out of order. After the receiving stack receives the
    packets it will send an ACK with the current information. For a
    SACK enabled connection
    these ACKs may not contain SACK blocks. This means the receiving
    side has not received any new out-of-order packets
    and the sending side should not treat this as a Duplicate ACK
    (DUP ACK).
    DUP ACKs can cause the sending side to trigger FRR and result in
    unnecessary retransmission of packets.

Problem conclusion

  • Code has been modified to not treat ACKs that contain no SACK
    blocks as duplicate ACKs (DUP ACKs).

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


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

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

    UI66775 UI66776



Fix information

  • Fixed component name


  • Fixed component ID


Applicable component levels

  • R230 PSY UI66775

       UP20/01/16 P F001

  • R240 PSY UI66776

       UP20/01/16 P F001

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":"230","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":"230","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 February 2020