[ssh_x509] HPN DynamicWindow

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Fri Sep 7 23:16:27 EEST 2018

ssh_x509 at roumenpetrov.info wrote:
> Hello,
> New branch https://gitlab.com/secsh/pkixssh/tree/hpn_dynwin is created 
> and just pushed on part of HPN patch set - DynamicWindow.
> Once again 1(standard) > 2(hpn) > 3 (no-npn). standard is about 2.8% 
> faster.

SSH protocol is uses "channels" to transfer data (rfc4254). Each side 
may open channel. To channel sided allocate initial window size, aka 
buffer size and maximum packet length.
Packet size is had coded to 32k (16k for x11 channel) and in Sep 2007 
window size is changed for 4*packet size to  64*packet size, i.e. 2M.
With transfer of data remote window size is decreased and if exceed 3 
packet size remote sends "adjustment" that restores size.

Empiric tests shows that change of windows size (4M) and adjustment when 
half of windows is used do not add value - performance is improved less 
then 1%. Also changes in maximum packet size do not change performance 
Remark: tested on 100Mb low latency network.

Data transfer is bidirectional.
On data "download" (reception) local window is decreased and adjustment 
is sent according local rules.
On data "upload (send) remote window is decreased and adjustment is 
received according remote rules.
With other words tuning of "channel window parameters" could be done 
separately without to depend from remote side.

HPN DynamicWindow patch does not follow above rule. In connection to HPN 
sever on client side "window size" is overridden by size of socket 
receive buffer. The logic must not depend of connection type due to 
bidirectional nature of channel.

Patch updates method channel_pre_open() :

+ /* this may not work and I may have to use a temp variable to hold the

+ remote window value in this function -CJR */

+ c->remote_window = MIN(c->remote_window, 2 * c->tcpwinsz); ... Above 
code is reason for decrease of performance. In tested configuration 
tcpwinsz is about 300k and remote_window is 2M.

More important point is that above modification breaks functional logic 
on "remote window"! It is updated on data send(upload) - decreased by 
data transferred and restored on adjust (when received).

Following table shows difference is performance depending from cipher. 
The performance of slow cipher is considered as basis value: 1,0.
| 1,29 | aes128-ctr                    |
| 1,15 | aes192-ctr                    |
| 1,03 | aes256-ctr                    |
| 1,34 | aes128-gcm at openssh.com        |
| 1,06 | aes256-gcm at openssh.com        |
| 1,32 | aes128-ctr                    |
| 1,14 | aes192-ctr                    |
| 1,00 | aes256-ctr                    |
| 2,92 | chacha20-poly1305 at openssh.com |

Table shows that fastest cipher chacha20-poly1305 at openssh.com (note it 
is used by default) outperform basis by 292%.

As is visible using faster cipher is more important for performance then 
tuning of "channel windows parameters".

In conclusion "HPN DynamicWindow" patch is not correct and its 
functionality does not add enough value.

Roumen Petrov

P.S. Patch adds client option TcpRcvBuf. Its use does not look correct - 
it must not depend for type of connection and should not impact channel 
window parameters.

More information about the ssh_x509 mailing list