UDT: Breaking the data transfer bottleneck

udt.sourceforge.net

16 points·beagle3··8 comments

I have worked with UDT in the past. It certainly had its advantages though wasn't always as robust as I'd like it to be. I hadn't noticed much activity with it the last few years though. What's with the current interest?

It was mentioned in the HPN-SSH thread: https://news.ycombinator.com/item?id=8329507#up_8330376

What's the tradeoff you make when using UDT over TCP?

Ugh, I am so sick of people implementing "reliable" transport on top of UDP.

If you need reliability, use TCP or SCTP. You do not know more than 25 years of industry experience developing and implementing transport protocols.

TCP gives you some guarantees that you might not need, but still have to pay for.

Both TCP and SCTP are in-order, which is what you frequently want but not always. We don't have a good, reliable messaging protocol that allows out of order messages, which can lead to increased latency that isn't necessary for some use cases.

This can cause much larger latencies for messages that have arrived but aren't delivered to the application because a previous packet was dropped and is awaiting retransmission

Message ordering is optional in SCTP¹.

① http://tools.ietf.org/html/rfc4960#section-6.6

TCP has well-documented failings on high-bandwidth, high-latency links. (referred to as LFNs (long fat networks) or "elephants"). The congestion and flow control algorithms in TCP are excessively conservative and end up massively under-utilizing the available bandwidth. Once a TCP connection has reduced its transmit rate (due to dropped packets indicating possible congestion), it requires successful packet receipts to increase its transmit rate (depending on latency).

Reply on news.ycombinator.com