bugzilla-daemon at mindrot.org
2023-Nov-18 09:39 UTC
[Bug 3634] New: IPQoS default should be changed to "none"
https://bugzilla.mindrot.org/show_bug.cgi?id=3634
Bug ID: 3634
Summary: IPQoS default should be changed to "none"
Product: Portable OpenSSH
Version: 9.5p1
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: Miscellaneous
Assignee: unassigned-bugs at mindrot.org
Reporter: daisuke.higashi at gmail.com
Created attachment 3760
--> https://bugzilla.mindrot.org/attachment.cgi?id=3760&action=edit
IPQoS none patch
In this trouble ticket, I propose to change the default value of IPQoS
option to "none none?. A patch is attached.
- Problem description
Starting with OpenSSH 7.8, the DSCP value for packets sent by OpenSSH
has changed to AF21 (interactive) /CS1 (bulk) [1]. After this change,
there have been numerous reports of poor OpenSSH performance [2]. The
cause of this problem is that some networks enforce various
restrictions (rate-limiter or policer) on some DSCP traffic and
OpenSSH?s new DSCP values hits this restrictions. The workaround for
this problem is to set IPQoS cs0 (DSCP=0) or to use old OpenSSH
version?s value (IPQoS throughput).
We cannot simply blame OpenSSH's new DSCP value for this problem. Nor
can we blame the behavior of the network; the real cause of this
problem is just that the combination of the network's QoS policy (which
varies from network to network) and OpenSSH's new DSCP values are not
compatible [3].
- Propose
To address this mismatch issue, OpenSSH should use DSCP=0 by default,
which is corresponding to the default PHB. Since most platforms use
DSCP=0 by default, OpenSSH should use platform?s default value. i.e.
?IPQoS none none" should be default setting for OpenSSH.
- DSCP=0 rationale
The default PHB (a.k.a best effort forwarding behavior) is a class
that networks must implement in Diffserv architectures, and it is
recommended that DSCP=0 is mapped to the default PHB [RFC2474 4.1]. In
practice most network applications use DSCP=0 by default and have not
experienced problems like OpenSSH. So DSCP=0 by default is considered a
good practice.
- References
[1] AF21/CS1 changes.
https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-April/036788.html
[2] Numerous reports of poor OpenSSH performance.
https://unix.stackexchange.com/questions/718686/unable-to-connect-to-anything-using-ssh
https://wiki.archlinux.org/title/OpenSSH#Broken_pipe
https://wiki.osuosl.org/howtos/ssh_ip_qos_fix.html
Or Google ?IPQoS OpenSSH?
[3] A real example of mismatch.
One of Japan's largest ISP is known that they treat CS1 (DSCP=8) as
high priority (low latency, low discard), but limit the amount of
incoming traffic to prevent the network from filling up with high
priority traffic. Many other ISPs use similar QoS policy (high priority
but rate-limited for certain traffic class) in practice.
While this QoS policy was to protect their network and their purpose
was NOT to limit OpenSSH performance, the mismatch between this QoS
policy and OpenSSH's new DSCP values results in OpenSSH's poor
performance.
--
You are receiving this mail because:
You are watching the assignee of the bug.