bugzilla-daemon at mindrot.org
2022-Nov-27 19:09 UTC
[Bug 3505] New: SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck
https://bugzilla.mindrot.org/show_bug.cgi?id=3505 Bug ID: 3505 Summary: SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck Product: Portable OpenSSH Version: -current Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org Reporter: mindrot at dimebar.com 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? -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2023-Sep-14 11:40 UTC
[Bug 3505] SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck
https://bugzilla.mindrot.org/show_bug.cgi?id=3505 Celeste Liu <CoelacanthusHex at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |CoelacanthusHex at gmail.com -- You are receiving this mail because: You are watching the assignee of the bug.