On 2/11/11 10:06 AM, so...@guug.org wrote:
On Thu, Feb 10, 2011 at 08:17:53PM -0800, Philip Prindeville wrote:
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.
It seems you are not getting it but it's very simple:
Linux by using the default pfifo_fast queue discipline always honours
QoS values in the TOS field even if you don't have "tc configured".
I wanted to clear up some confusion that the above comments may have caused.
There's a "TOS Octet" that was defined in RFC-791 as:
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
Bit 6-7: Reserved for Future Use.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Precedence
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine
So two fields, the Precedence field and 3 (later 4) bits marking ToS which were
supposed to be mutually exclusive (plus an unused field).
Eventually bit '6' was changed from MBZ (must-be-zero) to the 'C' (cost bit)
right about the time that NREN introduced pay-for-use Internet carriage in 1989.
The previous comment above incorrectly refers to the default linux scheduler
using the TOS bits (D/T/R/C); linux uses the Precedence bits (0-2)... and this
might be the source of the confusion for the author.
The Precedence bits were eventually retitled "Class-Selector" (RFC-2474/2475),
and the D/T/R bits were added as a sub-selector of the Class-Selector called the
Differentiated Service Class Points (RFC-2598)... that is the class-selector CS2 (for
instance, which is part of the upper 3 bits) also allows an additional 3 bits to specify
code points (Assured Forwarding AF21..AF23) within that class:
The DS field structure is presented below:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint
CU: currently unused
The latest reallocation of the lower order 2 bits is RFC-3168 which doesn't
materially affect QoS:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
ECN: Explicit Congestion Notification
Figure 2: The Differentiated Services and ECN Fields in IP.
As it re-attributes those two bits for Explicit Congestion Notification (from
"unused").
Note that even though it's a 6 bit field (i.e. 64 permutations), only 21 values
are currently defined (8+12+1, i.e. 8 class-selectors, 12 assured-forwarding
values, and expedited forwarding).
By default, the Linux scheduler uses the Class-Selector (i.e. what was
"Precedence" previously). The low-order DSCP bits are ignored. This is mostly
safe.
What this means is that OpenWRT and all those Linux home routers
honours the TOS field out of the box when routing packets, your patch
contradicts this fact and now OpenSSH will do weird things on a OpenWRT
router by setting DiffServ values in the TOS field which will trigger
unknown or incorrect behavior. In the best case users will not
notice/care.
So, to be clear, this was a misstatement. What should have been said was "Linux
[...] honours the Precedence field".
Also, since the high-order 3 bits continue to signify the Class-Selector which
has the same semantics as the old Precedence bits, one could use only the CS
values while ignoring the (lower-order 3 bits of) AF (assured forwarding) and
EF (expedited forwarding) without significant detriment... except perhaps to
SDP (media) payloads in SIP telephony.
Hopefully this puts us all on the same page.
-Philip
Hopefully your patch receives more discussion on upstream OpenSSH.
<snip>
As your patch was merged yesterday it's end of discussion for me.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
