5 ms·
This article was interesting and also frustrating to read. 1. There are very few numbers. In particular, improvement in performance under various circumstances
by fn-mote 5y ago
This article was interesting and also frustrating to read.
1. There are very few numbers. In particular, improvement in performance under various circumstances is _not_ given! If you dig around you can find their transfer time application [1], but there is no discussion on that page.
2. The basis for the improvement is not spelled out. (References are given, but you have to know the field - "acronyms only".) If I understand correctly, their contribution is the improved measures of congestion used. Their landing page just touts "don't use TCP"... which sounds like Step 0 of a very long process.
I admit, the title is basically accurate: "how to build" not "the performance of".
tl;dr: Start with existing work, simulate and improve incrementally.
I don't know anything about the field, but this article didn't lead me to understand any better. I'd love to know the real numbers they observed, which approaches didn't pan out, are they effectively using an error correcting code?
Anyway, it's certainly not an academic paper - just an advertisement.
[1] https://www.trytachyon.com/file-transfer-calculator https://www.trytachyon.com/file-transfer-calculator
- amelius 5y agoI just tried the calculator. It seems that if you're in "US Metro" or "Europe", then the transfer protocol is just as fast as TCP, is this correct? I wonder why this is the case. Is it because the routers play more fairly?
- jandrese 5y agoI would expect it means your service provider isn't dropping packets. Their protocol seems to just be more aggressive about not backing off in the face of packet loss, which is helpful if one of your links is a marginal radio connection. The cynic in me thinks they achieve better throughput because they don't play nice with TCP and monopolize the link while everybody else gets backed off.
- drpixie 5y agoI'm inclined to agree. Perhaps there's a place for a "fast" FTP protocol but I wouldn't want to be sharing the link with them ... imagine the cries going around the office ... "has the internet gone down again!?" For TCP transfers, I expect to see near 100% utilisation (if I'm not sharing bandwidth) but that's on wired (reliable) links.
- hansel_der 5y agonailed it. communication links are generally a shared resource (common good) and the experience will degrade for everyone if individual transfers/users aren't backing down voluntarily.
- ncmncm 5y agoYou can do better than TCP and still "play nice". Just using up exactly the bandwidth TCP refuses to use, as FASP does by default, gets you much faster transmission.
- hansel_der 5y ago> Just using up exactly the bandwidth TCP refuses to use There's not much good to say about ppl that "use up the space others refuse to use" at the queue in a store, thou. i.e. our network links are generally not designed to be used at full capacity b/c queueing is hard and buying faster/more gear is easy.
- ncmncm 5y agoThen let's not say it. Clearly you miss the point: any provisioned backbone bandwidth that does not carry a packet just goes to waste. Network backbone channels are not provisioned like your consumer-grade cable TV network endpoint hubs. Carriers pay for guaranteed capacity. When TCP fails to use bandwidth capacity, it is failing to use backbone bandwidth, not dodgy last-mile bandwidth. Even moreso: when so configured, FASP is having exactly zero effect on the actual bit rate of the TCP connections. Another TCP connection would compete for the same packet slots, slowing them all down. The FASP traffic does not slow down any of the TCP connections, but only competes with other FASP (or similar) traffic.
- jandrese 5y agoAnything that causes packet loss will slow down TCP. If you are fully saturating a link you will introduce packet loss. It's just how TCP works.
- ncmncm 5y agoAnd if you are fully saturating exactly the packet slots TCP would not try to use, then you are not introducing packet loss. That is just how FASP works.
- hansel_der 5y ago> The cynic in me thinks they achieve better throughput because they don't play nice with TCP and monopolize the link while everybody else gets backed off. sounds like BBRv1
- mcharawi 5y agoThanks for taking the time to read it! To address your concerns: 1. To give you an idea of the speed improvements, we transferred a 2GB file between Ohio and Singapore on AWS and were able to transfer it in 0:26 (seconds) using our protocol, vs 2:15 for SCP. 2. The basis for improvement is taking into account the changes in round-trip-time for a particular network path; these temporary increases are used as the primary congestion signal. We are not using error correcting codes, which are good for preventing the retransmission of packets but do not address the underlying problem of avoiding congestion in a network.
- Straw 5y agoHow much was SCP affected by TCP buffer size tuning?
- koprulusector 5y agoCan I ask a dumb question? Why SCP and not rsync?
- metadat 5y agoThere is no meaningful difference, at the end of the day they'll both be fine for measuring the base case of single-threaded TCP connection performance. I prefer rsync as well, but SCP works on more machines by default (no dependency on rsync being installed on the target host).