Re: [Curdle] SSH/QUIC draft

[denis bider <denisbider.ietf%gmail.com@localhost>]

That's one of the problems and it's solved in SSH/TCP for single-channel connections by implementing "no-flow-control", as you note. It's not solved for multi-channel connections, and it leaves several other problems of SSH/TCP unsolved.

The SSH/QUIC draft solves the flow control problem in the general case, for multi-channel connections, and solves the other several problems of SSH/TCP. :)

I have just uploaded a new version (-04) with improvements inspired by feedback from Ilari.

denis

On Sat, Jul 11, 2020 at 10:23 PM Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:

denis bider <denisbider.ietf%gmail.com@localhost> writes:

>For at least 7 years now, I've been pondering that TCP is a poor transport
>for SSH and should be replaced by UDP.

The problem isn't TCP, it's SSH, specifically SSH's terrible flow control
a.k.a. the SSH performance handbrake, which (for SFTP) layers TCP over TCP
over TCP.  The solution isn't to run it over a protocol that hides one layer
of the handbrake but to fix SSH's flow control problems.

And yes, I know that in theory a fix is possible if every implementation
everywhere is very carefully implemented and tuned to perform exactly the same
precise dance to avoid the handbrake, but better would be to fix the
underlying problem.

In my case for example I just ignore the flow control/handbrake, a.k.a. "no-
flow-control" if you can find anything that supports that, and get pretty much
line speed on data transfers.  OK, this is a bit antisocial, but it avoids
having to answer "why do I get an order-of-magnitude performance drop with SSH
vs.TLS when the same algorithms are used" questions.

Peter.