Re: SSH/QUIC draft

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-kVWAYfnMFF2W8ldZTk/[email protected]>
wrote:

> denis bider <[email protected]> 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.
>

_______________________________________________
Curdle mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/curdle