On 2/10/11 11:56 AM, so...@guug.org wrote:
On Wed, Feb 09, 2011 at 06:34:32PM -0800, Philip Prindeville wrote:
The default values for OpenSSH QoS markings are wrong.
They use 'lowdelay' and 'throughput' for interactive and bulk traffic,
respectively.
Unfortunately, these values were retired in 1998 when the low-order 2 bits of
ToS field were repurposed for DSCP: originally RFC-2474 marked the lower 2 bits
as 'CU' (currently unused), but they were eventually designated as ECT and CE
in RFC-2481 and then as ECT0 and ECT1 in Explicit Congestion Notification
(RFC-3168).
The upshot of all this is that marking traffic with these obsolete markings
could mean that not only is the traffic not handled as desired, but it's
handled in a highly detrimental fashion (for instance, the RFC-791 designation
of 'lowcost' collides with the ECT0 and CE values of RFC-3168 as well as that
of obsolete RFC-2481).
I'm surprised that this wasn't fixed a lot sooner (like a decade ago).
For whatever reason, while OpenSSH has accepted my patches for allowing the
configuration of QoS, the default values are still the obsolete ToS fields from
RFC-791 which is dangerously ancient (that part of the patch was left out).
The patch here itself is fortunately trivial.
DSCP markings will be ignored in the majority of equipment not implementing it
or where it has not been enabled.
If you're forced to interoperate with some seriously braindead gear like a 10
year-old bargain Taiwanese firewall or router that discards traffic with these
bits set (extremely rare but not unheard of), then your best bet is to turn off
QoS marking all together as:
IPQoS CS0 CS0
in both /etc/ssh/ssh_config and sshd_config.
A fix has been submitted for OpenSSH:
https://bugzilla.mindrot.org/show_bug.cgi?id=1856
With all respect real world usage is different.
The TOS field was defined in RFC-791 and is still used today by many
people including the pfifo_fast egress scheduler (the default) in the
Linux kernel. As just the IP precedence part was ever used or if used
with care it doesn't collide with ECN.
I don't see why it is obsolete, many organizations (including my
University) honours those fields internally. In the outside Internet
almost nobody honours TOS nor DSCP.
IMHO the correct answer is Active Queue Management (ACM) with ECN in
the border routers and something simple as TOS or VLAN priority
internally.
Facts:
All Linux routers by default honours the TOS field.
Big routers as used in the transport links in the Internet doesn't
honour neither TOS nor DSCP (net neutrality remember?).
DSCP does not obsolete TOS in the real world.
IPv6 does not obsolete IPv4 in the real world.
Many software supports TOS field but not DSCP.
In contrast with your point of view I believe TOS is used widely than
DSCP so current behavior should be preserved unless the admin wish to
change it.
Not sure what that means to say "all linux router by default honours the TOS
field" since that depends on how/if you have 'tc' configured, and which scheduler
you're using. On every box that I have that requires QoS, I've used the hfsc
scheduler... though a lot of my infrastructure is also Cisco stuff.
When I said "TOS" was obsolete, I was referring to the DTRC (delay, throughput,
reliability, cost) bits. Not the Precedence bits.
Openssh uses the DTRC markings (now obsolete), but not the precedence bits.
Actually, the latest ruling by the FCC reverses previous interpretations of QoS
markings, in that ISP's will soon be required to honor DSCP markings and give
users service that conforms to the markings they've requested... though the
details are still being banged out.
IPv6 is orthogonal to what I was saying.
As for "many software supports TOS field but not DSCP" isn't really the point.
It's moot to mark the traffic if the network doesn't support QoS. Equally important,
it's potentially detrimental to mark the traffic with TOS if the bits are being
interpreted as DSCP.
Most networks that I've used ignore the 802.1p markings or don't even use
markings (and just do straight 14-byte header encapsulation).
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
