[Bug 3634] New: IPQoS default should be changed to "none"

[bugzilla-daemon at mindrot.org]

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.