[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:
> 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%
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.
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
More information about the ssh_x509