PH18534: UNNECESSARY RETRANSMISSION OF PACKETS

Obtain the fix for this APAR.

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
  connections.
  
  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
  out-of-order
  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

Comments

APAR Information

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

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

  UI66775 UI66776

Modules/Macros

• EZBTCRD
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

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.