4 ms·

Thanks, we'll consider that, maybe as an option. Want to open an issue so we don't forget? I'd probably learn toward CUBIC: https://en.wikipedia.org/wiki/CUBIC

by mholt 4y ago

Thanks, we'll consider that, maybe as an option. Want to open an issue so we don't forget? I'd probably learn toward CUBIC: https://en.wikipedia.org/wiki/CUBIC_TCP https://en.wikipedia.org/wiki/CUBIC_TCP (I implemented Reno in college, but times have changed) The nice thing about Caddy's failure mode is that the server won't give up; the server has no control over if or when a client will time out, so it I never felt it made much sense to optimize for that.

skyde 4y ago
thanks for considering the feedback! What i was trying to explain is Server not giving up is never a good thing under congestion. This is why in ip switches they drop packet when the outbound queue is full. And letting the caller retry sending the packet. When there is no congestion it’s ok for the server to not timeout at all and wait for the queue to drain and let the client decide when to close the tcp connection. but when there is congestion you don’t want the queue inside the server to get too long. Because the server ( including caddy) might be behind a tcp load-balancer so it’s better for the client to queue it’s request inside another Caddy instance that is less busy. feel free to reach out to me at maxime.caron@gmail.com I would be happy to try to add it to Caddy if you are interested