-1

What would be some suitable transport and application layer protocols for a secure payments network where low latency is a key goal?

Here "low latency" means completing an encrypted transaction as fast as is possible given current networking technology, taking much less than one second for the networking bits, all round trips included, not counting human activity. Assume distances of no more than 1,000 miles (1609 km).

In this scenario, messages would usually occupy a single packet of perhaps 1 KB size. It would be slightly bursty in that discrete transactions would trigger brief bursts of traffic, while most clients most of the time would be idle.

Reliability is important, where "reliability" means something like 99% of sessions succeed on the first attempt. At this stage reliability doesn't refer to its common usage in describing networking protocols as "reliable" – I wouldn't want to bias the process by smuggling in implementation details like reliability at the transport layer...

At the transport layer, I'm aware of TCP, UDP, SCTP, Reliable UDP, DCCP, and things I don't understand yet like Enet.

At the application layer, I'm aware of HTTPS/TLS/HTTP/2, and QUIC / HTTP/3. (I think QUIC might collapse some layers and simplify things, so maybe it also encompasses the transport layer.)

What would you recommend? Do you think UDP can meet the reliability target under typical internet conditions? Perhaps UDP wrapped in application layer reliability, such as QUIC? Or do you think TCP can hit the latency target?

Does your recommendation change if we assume a private network where any protocol can get though middle boxes and such? I'm intrigued by SCTP – any thoughts there?

Thanks much.

  • Send the same packet 15 times by UDP? You can't really get lower latency than that. – user253751 Jul 2 at 13:59
  • 15 times? You mean to make it super reliable or something? – LearningFast Jul 2 at 18:27
  • 15 might be overkill, but just in case one of them gets randomly dropped. That's the lowest latency you'll get. Everything else involves waiting for a round trip, and some protocols need several round trips. – user253751 Jul 2 at 18:28
  • And then you can detect whether the server actually got the message, and retry if it didn't, but at that point, your lowest possible latency goal has been completely destroyed because you had to wait for a timeout. – user253751 Jul 2 at 18:30
  • @user253751 that misses the reliability part. Every sent packet is indenpend. You still have no way to ensure it got there. – Pedro Rodrigues Jul 7 at 19:22
2

For lowest possible latency you don't have a chance to have a back-and-forth conversation with the server. You can send a packet and that's it. To increase reliability, you can send 10 or 20 packets and hope that at least one doesn't get dropped.

Anything else is not low latency. All protocols - including QUIC, TCP, SCTP, Enet, and your own custom one - detect dropped packets by timing out and retrying. That means you need to wait for the timeout. That means there is extra latency.

But, then you said 1 second. 1 second is actually not very low. You can send a packet all the way around the world 3 times in 1 second. So it comes down to setting a short retry timeout and minimizing round trips.

In the worst case, where your packet has to go all the way around the world, extra round trips are very noticeable. They take about 0.3 seconds each. But you said the maximum distance is about 1000 miles. It doesn't take 0.3 seconds for a packet to go 1000 miles and back (usually), so you could use a low timeout, like 100ms. That would let the program time out and resend the packet several times before hitting the one second limit. The server needs to be prepared to handle duplicate packets, of course, in case the packet takes more than 100ms to get there and back.

Note that it doesn't matter whether you implement this with TCP or QUIC or UDP - the fundamentals are the same. The only reasons you might not be able to use TCP are that the operating system doesn't let you set the timeout that low, or that the extra round trip for the handshake is unacceptable.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.