We had a great response to last week’s Webcast “Controlling Congestion in New Storage Architectures” where we introduced CONGA, a new congestion control mechanism that is the result of research at Stanford University. We had many good questions at the live event and have complied answers for all of them in this blog. If you think of additional questions, please feel free to comment here and we’ll get back to you as soon as possible.
Q. Isn’t the leaf/spine network just a Clos network? Since the network has loops, isn’t there a deadlock hazard if pause frames are sent within the network?
A. CLOS/Spine-Leaf networks are based on routing, which has its own loop prevention (TTLs/RPF checks).
Q. Why isn’t the congestion metric subject to the same delays as the rest of the data traffic?
A. It is, but since this is done in the data plane with 40/100g within a data center fabric it can be done in near real time and without the delay of sending it to a centralized control plane.
Q. Are packets dropped in certain cases?
A. Yes, there can be certain reasons why a packet might be dropped.
Q. Why is there no TCP reset? Is it because the Ethernet layer does the flowlet retransmission before TCP has to do a resend?
A. There are many reasons for a TCP reset, CONGA does not prevent them, but it can help with how the application responds to a loss. If there is a loss of the flowlet it is less detrimental to how the application performs because it will resend what it has lost versus the potential for full TCP connection to be reset.
Q. Is CONGA on an RFC standard track?
A. CONGA is based on research done at Stanford. It is not currently an RFC.
The research information can be found here.
Q. How does ECN fit into CONGA?
A. ECN can be used in conjunction with CONGA, as long as the host/networking hardware supports it.