IPFE Connection Unexpectedly drops after about 10mins and diameter unknown error 3010 seen after connection drops

Asset ID:	1-71-2310028.1
Update Date:	2017-10-19
Keywords:

Solution Type Technical Instruction Sure

Solution 2310028.1 : IPFE Connection Unexpectedly drops after about 10mins and diameter unknown error 3010 seen after connection drops

Applies to:

Oracle Communications Diameter Signaling Router (DSR) - Version DSR 5.0 and later
Information in this document applies to any platform.

Goal

Why does IPFE drop a connection after about 10 minutes. The diameter unknown error 3010 was seen after the connection dropped but the real issue was why is the connection dropping. The 3010 error was an effect of using a simulator.

Solution

The delete age on the IPFE is sent to 600 secs and more importantly the DWA being sent by the peer does not have the TCP Push Flag set. The active IPFE does not update the association with the receipt of the DWA if the TCP Push Flag is not set hence the connection is aged out after 600 sec (10 minutes). See attachment for example of TCP Push Flag Not Set.

-----------------------------------------------

The following subsequent questions were raised about this issue and the questions answered. Response are included here to help in the understanding of the issue and resolution

1. Why this issue is happening after the upgrade 7.3.1 release?
3. Is there any engineering design changes for IPEF/DAMP server in 7.3.1 release?
(Oracle) Addressing both questions above, IPFE introduced several important features in DSR7.0/7.1 including the TCP Push Flag.
From an IPFE implementation standpoint, it does have the assumption that Diameter TCP data messages are always with PUSH-bit set.
Since currently customer is using the simulator for packet generation we don't believe the customer production will meet this issue.

2. Why do we need to change the TCP Push flag set? (I believe TCP Push flag is used for buffer setting)
(Oracle)

The setting of the Push Flag is not controlled by the sending application, but by the sending TCP layer.
The PSH flag is only NOT set if for example the sending side transmits more data than fits in a single segment,
in which case only the last segment will have PSH set, indicating there's more data coming up for now.

The following link has some information you may find useful in relation to TCP Push: http://packetlife.net/blog/2011/mar/2/tcp-flags-psh-and-urg/

But in general, buffering is good for the efficient data transfer when sending data with more than the maximum segment size (i.e., a very large file). However buffering can become an issue when dealing with real-time applications and there is a desire to transmit the data as quickly as possible.
The TCP Push flag helps to alleviate the issue such that when the Push Flag is set the receiving side knows to forward the segment to the upper layer immediately. Hence TCP push is typically expected in real-time communication such as with Diameter messaging.

As mentioned above we expect that production networks with real-time communication will use diameter messages with TCP Push Flag set.

References

<NOTE:2294132.1> - Responder Connections through IPFE are unstable. Device Watchdog (DWR) message appears to be forwarded to a different MP and thereafter DSR terminates the connection
<NOTE:2106578.1> - Connection Between Diameter Routing Agent (DRA) and Client is Going Down Frequently, DRA is Sending Transmission Control protocol (TCP) Reset Message to Bring Down the Connection

Attachments

This solution has no attachment