Hacker News new | ask | show | jobs
by eadan 2198 days ago
My understanding is that the protocol underlying Aspera (FASP) uses UDP for the main data transfer and a TCP connection for coordination. By using UDP for data transfer it's not restricted to the ACK ranges imposed by TCP which can hinder throughput on networks with relatively high packet loss. Its throughput is not necessarily achieved by being a "bad citizen" but by having full control over how and when it communicates lost packets.

Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc.

Btw. there are open protocols like Tsunami UDP (https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol) that try to fill the same niche

1 comments

My understanding is that window scaling and SACKs enable TCP to detect losses within large segments too. The only limitation is that most congestion controllers throttle back when detecting packet loss. Newer latency-based controllers don't suffer from that problem.
This is interesting. I haven't seen much in regard to comparing TCP+BBR to FASP other than a masters thesis which suggests FASP outperforms on transferring large files over long distances (which is exactly its intended purpose). But, I wonder if splitting a file over multiple QUIC connections and re-assembling at the other side would come closer to the performance of FASP? Could be a fun experiment, I might try it!
An optimal CC should have high utilization with a single stream¹ and behave fairly to other connections on the network. Measuring multiple streams misses the point of the exercise.

> other than a masters thesis which suggests FASP outperforms on transferring large files over long distances

I found that one too. I would take it with a grain of salt since it uses scp for data transfer (which has its own flow control and may be the limiting factor here) and doesn't list the values of some important tcp settings, e.g. tcp_wmem, which can be essential for transoceanic connections.

¹ ignoring the case where a single CPU core can't move bytes fast enough to saturate a link.