Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

If you're not seeing full network utilization to the extent permitted by your TCP stack (note that the TCP stack may itself be throttling you below network potential), then the problem is very likely either mismanaged channel window size (probably in the sending direction), or insufficient SFTP request pipelining.

In general, the channel window must be large enough that the sender doesn't get throttled by the window size before the receiver can respond with a window adjust. The size required increases linearly with a multiple of connection latency and bandwidth.

Note that the required window size for full throughput can be fairly large with long fat pipes; WAY larger than would be appropriate for a slow, low-latency connection. If you're sending at 40 Mbps (which is not even that fast now) across the Atlantic or Pacific (200 ms round-trip) you need a window size on the order of 1 MB. If you want to send at gigabit speeds with same latency, you need appropriately more; e.g. 20 MB.

The SFTP performance problem can be solved, and we believe it to be solved in our software, using both appropriate window sizing and SFTP request pipelining. So the "no-handbrake" extension is not strictly NECESSARY, it's possible to reach network potential without it.

What the "no-handbrake" extension does is remove a level of complexity for people writing simple, special-purpose SSH implementations, who want to achieve decent performance without having to make a PhD out of it. If the channel window sizing implementation is poor, then if "no-handbrake" is not available, performance will suck. But if it's available, performance will be as good as the TCP stack permits (which is written by professionals).

If you have a multipurpose implementation that supports multiple channels, I think you should just do channel window sizing properly. I would not like general-purpose, multichannel implementations resorting to this. You're already accepting a higher level of complexity by supporting multiple channels; so why not do it right.


----- Original Message -----
From: Niels "Möller" 
Sent: Friday, November 13, 2015 00:21
To: denis bider 
Cc: Peter Gutmann ; [email protected] ; Jeffrey Hutzelman ; Mark D. Baushke ; [email protected] ; [email protected] ; [email protected] ; Max Horn 
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis bider <[email protected]> writes:

> It seems to me the only known applications that might want to use
> "no-handbrake" are those that don't want to use multiplexing. I don't
> know of a different usage case.

One usecase: Make make s single general-purpose connection from my
workstation to my server, using it for one or more shell sessions, port
worfwarding, etc. I use "connection sharing", i.e., a local private unix
socket that can be used to create additional channels over the same
connection.

Then I decide to do a large file transfer, so I create a new channel
just for that purpose, and I really want it to finish as soon as
possible.

Now, this is a problem in my implementation which I haven't yet bothered
to solve, because it uses a fix and pretty small window size, and
typically I won't get close to full network utilization. So I don't know
if it's good enough to just set a much larger window size (but if it
doesn' I think that ought to solve all "no-handbrake" usecases).

> In this situation, you must stop reading from the SSH socket, which
> affects all channels.

Agreed. And we should note that the "no-handbrake" will not work well if
the bottleneck of the data flow actually is after ssh, so users need to
enable it with care. One option might be to timeout after a few seconds
and close the connection; then we kill the affected channel, without
hanging the connection indefinitely.

> The way I see it, the only clean usage scenario for this feature is
> where there's a single channel.

Also in this case, if you get overwelmed with data, you have to stop
reading the ssh socket, and hence making timely key reexchange
impossible.

> That's why I think it makes sense to negotiate it on the transport
> layer. The transport layer must be aware of this.

Maybe. but I'd prefer a solution to both the single-channel use-case and
the usecase above. I think we need to take a step back and sort out what
the use cases are. I've been thinking that the poor utilization I've
seen is simply a sign of poorly chosen window sizes in my
implementation. If it's a more general problem, we need to understand
what the usecases and failure modes are.

A different solution which I've been considering is a channel mechanism
to automatically increase the window size when the ssh flow control is
the bottleneck. It could be as easy as checking on reception of
SSH_MSG_DATA if the receive window goes down to 0, and if so increase
the size of the receive buffer and send a WINDOW_ADJUST which reflects
not delivery of data, but the increased buffer.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.