3 ms·

Rate control sounds nearly identical to TCP Vegas then, no? But out of order delivery and (I'm guessing) out of order retransmits appear to be unique to fasp.

by eps 7y ago

Rate control sounds nearly identical to TCP Vegas then, no? But out of order delivery and (I'm guessing) out of order retransmits appear to be unique to fasp. What did you mean about these being unique "until recently"? [edit - nevermind, saw below you were referring to sack] PS. I remember looking at fasp ~10 years ago and it looked like a fantastic tech. Someone's taking things that many people only talked about and putting them into a product that really worked well. Cutting edge stuff. A job like - a dream for many :)

fanf2 7y ago
And more recently Google's BBR is a newer delay-controlled congestion control algorithm - http://www.potaroo.net/ispcol/2017-05/bbr.html http://www.potaroo.net/ispcol/2017-05/bbr.html So it'll be interesting to see if BBR+QUIC can be made to do what FASP does.
ncmncm 7y ago
No, quite different from Vegas, if the graphs are to be believed. What I would see on real trans-oceanic links was a sub-second ramp up to a flat, stable rate, and stepwise rate changes during the session as other flows started and stopped, with no visible oscillation. (I am looking at https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/ https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/ .) Fasp does not rely on RTT ACK timing, which is very noisy, but only outgoing delays. The routers are applying their own algorithms to simulate sane queue timing, but they are doing all kinds of crazy shit under the hood to get better link performance. The queues, IOW, are a fiction provided to the endpoints to simplify their job and generate understandable, thus tunable full-route dynamics. But the ACKs get completely different treatment, because traditionally nothing cared about ACK timing. So, "onset of queuing", e.g., is pretty meaningless in practice, and fasp makes no attempt to detect it.

by eps 7y ago

fanf2 7y ago

And more recently Google's BBR is a newer delay-controlled congestion control algorithm - http://www.potaroo.net/ispcol/2017-05/bbr.html http://www.potaroo.net/ispcol/2017-05/bbr.html So it'll be interesting to see if BBR+QUIC can be made to do what FASP does.

ncmncm 7y ago

No, quite different from Vegas, if the graphs are to be believed. What I would see on real trans-oceanic links was a sub-second ramp up to a flat, stable rate, and stepwise rate changes during the session as other flows started and stopped, with no visible oscillation. (I am looking at https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/ https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/ .) Fasp does not rely on RTT ACK timing, which is very noisy, but only outgoing delays. The routers are applying their own algorithms to simulate sane queue timing, but they are doing all kinds of crazy shit under the hood to get better link performance. The queues, IOW, are a fiction provided to the endpoints to simplify their job and generate understandable, thus tunable full-route dynamics. But the ACKs get completely different treatment, because traditionally nothing cared about ACK timing. So, "onset of queuing", e.g., is pretty meaningless in practice, and fasp makes no attempt to detect it.