Statistics Flow Graph Data Connection

The client starts the TLS handshake immediately after the 3-way handshake.
Not receiving an ACK in time, the client's TCP stack retransmits the ClientHello with increasing intervals,
still not getting an ACK.
The acknowledgement from the FTP server 1.9 seconds into the session carries a sequence number of 2821
which implies thatthe server (was trying to) sent 2820 bytes - which must have been its Server Hello.
Unfortunately the Server Hello never made it to the client.
The Client gives up 300 seconds after the session was started and closes its socket causing a RST packet to
flow to the server.

This looks like the client is unable to open the data connection and times out after having retransmitted the Client Hello 2 times.

The connection goes through a firewall.
With out SSL/TLS security an FTP data connection would always have traffic in one direction only
For a for PUT all data packets would flow from client to server, for a FTP GET all packets would flow from server to client.
So many firewalls have a check to allow only unidirectional flows on FTP-Data sessions.
As the ClientHello is the first packet to flow, the firewall will only allow data in this direction and therefore drops the server's
Server Hello.
We recommend to allow for bidirectional ftp data traffic in the firewall as per https://ibm.biz/BdXvLS

zOS FTP Client presenting Cipher x'0039' TLS_DHE_RSA_WITH_AES_256_CBC_SHA indicates  that they are using AT-TLS.
Cipher x'0039' would not appear if FTP client is configured for TLSMECHANISM FTP.
Customer could gain a one up if he changes his TTLS rules to: - enable TLSv12 and - move cipher 0039 on top of his cipher list.