B2B abruptly fails to communicate to the FTP serverr

Scenario:-There was a scenario in my project where we had Inbound transaction 895s configured for a trading partner and we had to send a Functional Acknowledgement(997) back to the TP for each 895 received.

Problem:- We had hundreds of 895s coming at a time into B2B and while B2B was sending 997 for each 895, some of the 997 edi files failed at the FTP Server. That meant some of the 997 edi files failed to appear at the FTP location while the rest of them were successfully created.
Error in the B2B logs-
oracle.tip.transport.TransportException: Unable to read response from host '$FTP HostServer'
java.net.SocketException: Connection reset

Cause:-As problem was very strange because B2B was abruptly loosing connections to the FTP and the FTP server logs were clean too, we couldn't drill down to the exact cause of the problem, so we concluded that this issue is intermittent and the possible cause could be network or environment issue.

Solution:- Since we were not able to do a root cause analysis (even after seeking help from Oracle support) and at the same time we also needed a workaround to come out of this situation, we used the Retry Count facility available at the Delivery channel layer of the TP. By setting the Retry Count and Retry Interval to some specific value,we were actually cutting down the possibility of the connection failure between B2B server and the FTP.

Result :-The B2B was successfully able to connect to the FTP in the one of the retry attempts if it anyhow failed in the previous attempt.
Its better to configure the retry mechanism for each EDI transaction beforehand.

Cheers
Ayush