Archived
This forum has been archived. Please start a new discussion on GitHub.
TCP/IP Retransmissions
Hi there,
One of our apps is sending multiple 2MB objects from one client (C#) via ICE to another client (C++) over a 10GB link.
The submission of objects is sync (we need to detect when the C++ client cannot accept the object and redirect immediateley all obejcets to another C++ client)
Once in a while, a TCP problem occurs and the protocol initiates a retransmission. After this the entire traffic becomes very slow for a number of secons, as detailed here:
15:59:00.91 – retransmission is detected
15:59:01.53 – all data has been retransmitted/recovered
15:59:01.53 – C++ client sends back an ICE message “Success”
15:59:01.53 – C# client sends and ICE submit.message()
At this moment for a number of seconds (2...9) traffic volume between the tow clients is very low. After that it picks up.
Do you know of anything at packet loss/ retransmission in the ICE interface that can cause this?
Thanks.
One of our apps is sending multiple 2MB objects from one client (C#) via ICE to another client (C++) over a 10GB link.
The submission of objects is sync (we need to detect when the C++ client cannot accept the object and redirect immediateley all obejcets to another C++ client)
Once in a while, a TCP problem occurs and the protocol initiates a retransmission. After this the entire traffic becomes very slow for a number of secons, as detailed here:
15:59:00.91 – retransmission is detected
15:59:01.53 – all data has been retransmitted/recovered
15:59:01.53 – C++ client sends back an ICE message “Success”
15:59:01.53 – C# client sends and ICE submit.message()
At this moment for a number of seconds (2...9) traffic volume between the tow clients is very low. After that it picks up.
Do you know of anything at packet loss/ retransmission in the ICE interface that can cause this?
Thanks.
0
Comments
-
Does the Ice protocol retry, or the underlying TCP stack? You can monitor the Ice retry behavior by setting the property Ice.Trace.Retry=2. Ice does not modify the TCP stack in any way with respect to retransmission of data.0
-
The retry is generated by TCP.
I will add the monitoring of ICE retry, but our main question is why after a TCP retry the next ICE communication is so slow...
Thanks.0 -
The retry is generated by TCP.
I will add the monitoring of ICE retry, but our main question is why after a TCP retry the next ICE communication is so slow...
Thanks.
I don't think this has anything to do with Ice. As I wrote above, Ice does not modify the TCP stack in any way, so you would probably see the same behavior with any application that uses TCP/IP directly.
What Ice version are you using, and what platform is this, and what network do you use that provides 10GB/s speed?0
