3 ms·
Since the article is from 2001, is this still true today?
by supahfly_remix 6y ago
Since the article is from 2001, is this still true today?
- marcosdumay 6y agoNearly every thing in that article is still true. The algorithms changed a bit, but I don't think they interact any better now. Instead, the failures should have become worse because buffers got larger. Still, TCP over SSH works. It's not perfect, but the problems are almost not noticeable. It used to work by 2001 too. There is something that makes all of that to not apply most of the time. I believe that unused capacity makes the problem possible to recover from.
- supahfly_remix 6y agoGreat, thanks for the reply.
- throwaway2048 6y agoThis article does not apply to TCP over SSH, as in SSH port forwarding (not openssh's VPN feature), in that case the timers are tied together and you don't get the crappy cascading behavior.
- shandor 6y agoThat sounds very interesting. Do you have any technical sources that I could delve deeper into? I've always thought that SSH tunneling / port forwarding suffers from the exact problems outlined in TFA.
- throwaway2048 6y agoAs I understand it, ssh "unwraps" the TCP stream back into a regular byte stream, then sends that, and reconstitutes it back into TCP packets on the other end.
- shandor 6y agoThanks. That sounds like a reasonable explanation, and anecdotally I don't remember ever having major performance problems with SSH, even on mobile networks, so it makes sense that there ia something preventing this particular error mode.
- jandrese 6y agoIt works until you get packet loss. On a modern broadband connection doing just web browsing/email/etc... it will be fine. Even bulk data transfers will be ok as the packet loss will be spread out so you don't get the cascading failures mentioned in the article. The whole scheme could come crashing down if you're running over WiFi and your neighbor starts blasting out traffic on the same channel though.