Page 1 of 1

Implications...

PostPosted: Apr 21st, '20, 21:45
by jiml8
Instances of my device control both ends of a very high latency communications channel. The communications across the channel are generally TCP protocol.

I have been asked by the provider of the communications channel if I could spoof TCP ACK packets at both ends of this channel in order to speed things up. Basically, the systems that are communicating over this link send their packets through my device then over the communications link. My device sees the incoming packets, analyzes them, and if appropriate sends an ACK back to the originating system thus spoofing the ordinary response to the packet and signaling that another packet can be sent.

This will speed up the communication at the cost of reducing its reliability.

Now, my answer to them is "yes, I can do this and it won't be particularly difficult. But, do you really want me to?"

So, I am interested in anyone's opinions here about the implications of spoofing ACK for this purpose. The implications I see are possibly getting the communications out of sync and forcing retransmits. Does anyone else see any other things?

Re: Implications...

PostPosted: Apr 22nd, '20, 00:36
by doktor5000
Dumb question, but how does adding another device into the mix speed up the transmission? 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 ?

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) ?

FWIW, you probably already know that, but might still be worth reading, even if it's not that recent:
https://forums.whirlpool.net.au/archive/116165
https://www.psc.edu/index.php/networking/641-tcp-tune

Re: Implications...

PostPosted: Apr 22nd, '20, 01:11
by jiml8
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.