doktor5000 wrote:Dumb question, but how does adding another device into the mix speed up the transmission?
No new device. My (our) device is on both ends of the link. The carrier is asking if we can modify it to spoof the ACKs in an attempt to speed up communications.
You want to basically send forged ACK responses to the sending device, so that it will keep sending, before the actual packets arrive at the receiving end - did I understand that correct ?
Exactly.
Wouldn't you be better off checking if stuff like if nagle algorithm should be disabled, or if you can use quickack, or maybe selective ACK is disabled or something like that ? Or maybe increase the TCP window sizes, and affect the BDP (bandwidth delay product) ?
Won't help.
The problem is that the communication channel is a satellite link to satellites in geosynchronous orbit. We have partnered with the carrier to provide endpoints for their system. Their system plus our system provides a capability that they badly need, while giving us a new market and a sometimes useful alternate communications pathway for our SDWAN product.
This pathway has an inherent and non-reducible bi-directional latency of 750 ms. Nothing to be done about it; it's physics.
Our product on their link is working quite well, doing everything that is asked of it. But TCP is very slow given this long delay. We can sent big packets (Nagle's algorithm) but still there is a long wait for the ACK.
The carrier wants to be an alternative to terrestrial connections in all cases, but this physics is biting them. Things work great with UDP or with most other serial protocols, but TCP is a problem for them. So they are asking if I can spoof the ACKs locally to get the system to send another packet.
Yes, I could. My ack would reach the sending system in less than a millisecond after they sent the packet, probably, and it could then send another packet. My fear is that we would then have packets arriving every couple milliseconds on the other end, and this would confuse the system on the other end and result in discarded packets and requests for retransmits. I could delay the ack 20 or 30 ms, but I still have to wonder if this is a practical idea.
I'm kind of swamped right now and I don't really want to put the time into this if it won't work. And I am not sure it will work.