IBM Z Software
This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
The z/TPF system today does not necessarily "flood" the network with retransmits. In the case of large window sends, most times lost packets are detected with fast retransmission (duplicate ACKs being received from remote end) asking for the same packet over and over. In this case, TPF retransmits the packet requested, plus any additional packets sent in the same OSA write buffer. So, generally we would only be retransmitting a handful of packets.
The belief is SACK support can help in some cases, but can also hurt in others. The cost and risk of implementing SACK on TPF is high, and the thought is the reward is minimal as a network that is suffering will continue to suffer with or without SACK support enabled. The retransmitted packets when an event occurs are negligible compared to overall throughput of packets coming from TPF so we believe SACK would provide little to no value.
Because the RFE was opened with a low priority and this will take months of effort and it is not clear whether this will truly help throughput during networking events, we are going to reject this RFE.
-------------------------------------------------------------------------------------------------------------------------------------------------
Ideally both would be nice, with SACK being controlled on socket creation by some parm (IOCTL?) but if TPF responded to selective ACKs by retransmitting only the packets asked for (#2) that would help considerably.
We have processes where TPF does most of the sending and if it has to retransmit all the packets, especially over long distances the data begins to queue up.
Selective Acknowledgments is a negotiated option on the TCP handshake. If TPF were to add support for this, which pieces of support for TPF would be required:
1. TPF sending selective ACKs outbound, to minimize the amount of retransmitted packets from the remote side?
2. TPF responding to selective ACKs by retransmitting only the packets asked for by the remote side
3. Or would both be required.
Selective activation is a fairly significant effort. What problem are we trying to solve with SACK? If the number of retransmits is very low, the impact of implementing SACK on z/TPF would have little to no value.