Implications...

Here wizards, magicians, sorcerers and everybody can rest a bit and talk about anything they like.

Just remember to respect the rules.

Implications...

Postby jiml8 » Apr 21st, '20, 21:45

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?
jiml8
 
Posts: 1132
Joined: Jul 7th, '13, 18:09

Re: Implications...

Postby doktor5000 » Apr 22nd, '20, 00:36

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
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 16127
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Implications...

Postby jiml8 » Apr 22nd, '20, 01:11

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.
jiml8
 
Posts: 1132
Joined: Jul 7th, '13, 18:09


Return to The Wizards Lair

Who is online

Users browsing this forum: No registered users and 1 guest