Bug 3505 - SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck
Summary: SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Miscellaneous (show other bugs)
Version: -current
Hardware: Other All
: P5 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-28 06:09 AEDT by P Rowlands
Modified: 2022-11-28 06:09 AEDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description P Rowlands 2022-11-28 06:09:06 AEDT
tl;dr: Should we increase the maximum channel window size to allow higher throughput for WAN data?


https://github.com/openssh/openssh-portable/commit/395ecc2bdeefd86a31562dd4145f370b816814bd
committed on 2007-06-12 is still the current #define for CHAN_TCP_WINDOW_DEFAULT.

64*32*1024 = 2 MiB, but in 2022, I predict that networks are faster on average than in 2007.

Some examples for 2 MiB BDP:
- 200ms @   84 mbps
- 100ms @  168 mbps
-  50ms @  336 mbps
-  25ms @  671 mbps
-  12ms @ 1398 mbps
-   6ms @ 2796 mbps
-   3ms @ 5592 mbps

Not everyone runs networks which exceed these parameters, but we do on high-latency WANs.

The problem I'm seeing is the artificial bandwidth restriction resulting from CHAN_TCP_WINDOW_DEFAULT being supplied to channel_new's local_window_max.

It doesn't matter how much memory is given over to TCP buffers; because OpenSSH (and scp, and rsync) receivers limit the channel window to 2MiB, an artificial speed limit exists.

After 15 years of
#define CHAN_TCP_WINDOW_DEFAULT (64*CHAN_TCP_PACKET_DEFAULT)

is it time for an increase? If not now, when? If not an increase, perhaps a config option?