<div dir="ltr">G'day,<div><br></div><div><div><div>TLDR; I think the current openssh TOS settings of AF21 and CS1 are a poor match for the old TOS bit fields and are causing confusion. IMHO AF22 and AF11 would be a better backwards-compatible choice. I think the iptables use of "08x/0x3f" for Maximize-Throughput is only wrong in that the mask 0x3f includes 1 bit of the DSCP "Precedence" field.</div><div><br></div></div><div></div></div><div>I sent a message to <a href="mailto:923879@bugs.debian.org">923879@bugs.debian.org</a> which bounced because it's closed/archived, and found this bug as probably the most relevant open bug.</div><div><br></div><div>Reading this bug it looks to me like RFC 1349 confused Peter Lebbing by using less-common big-endian bit numbering for their bit labels in the TOS field and not making that very clear. Everything else I've seen has the precedence bits in the Most-Significant-Bits of the octet including these;</div><div><br></div><div><a href="http://www.rhyshaden.com/ipdgram.htm">http://www.rhyshaden.com/ipdgram.htm</a></div><div><a href="https://my.ezycloud.com.au/knowledgebase/201204284/Quality-of-Service-QoS----DSCP-TOS-CoS-Precedence-Conversion-Chart.html">https://my.ezycloud.com.au/knowledgebase/201204284/Quality-of-Service-QoS----DSCP-TOS-CoS-Precedence-Conversion-Chart.html</a><br></div><div><br></div><div>This is the convention ssh is currently using when it sets AF21 as 0x48 and CS1 ax 0x20, and this appears to be what IP tables is also using.</div><div><br></div><div>This means I believe that iptables use of "08x/0x3f" for Maximize-Throughput is only wrong in that the mask 0x3f includes 1 bit of the DSCP "Precedence" field. I think the correct mask should be 0x1f, though maybe there are reasons why you'd want to explicitly clear the LSB of the DSCP Precedence field that I'm unaware of.</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">I stumbled upon <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879</a> trying to figure out problems with my QoS firewall setup and a recent Debian ssh which is using AF21 and CS1 for interactive and bulk traffic respectively. This is the new ssh upstream default, and after speaking to one of the ssh developers (dtucker) it seems TOS standards are a mess and everyone they've spoken to have given them different advice. There are now more than two RFCs and 100k of text per TOS header bit. The choice of AF21 and CS1 was taken as an attempt to pick the least-wrong option, and no-one has been able to clearly justify anything better.<br></div><div dir="ltr"><div><div><br></div><div>The reason AF21 is being classified as "Maximize-Throughput" is because AF21 sets the (old?) Maximize-Throughput bit, not the Minimize-Delay bit, despite the various DSCP docs describing AF21 as "interactive" (actually, all of AF2[123] is documented as for "low latency traffic"). Note CS1 doesn't set any of the old Delay/Throughput/Reliablity/Cost TOS bits so is likely classified as "normal" traffic, not "bulk" by most older QoS systems. See the following chart for details;</div></div><div><br></div><div><div><a href="https://my.ezycloud.com.au/knowledgebase/201204284/Quality-of-Service-QoS----DSCP-TOS-CoS-Precedence-Conversion-Chart.html" target="_blank">https://my.ezycloud.com.au/knowledgebase/201204284/Quality-of-Service-QoS----DSCP-TOS-CoS-Precedence-Conversion-Chart.html</a><br></div><div></div></div><div><br></div><div>It appears from the settings that AF21 was intended for important high-volume traffic. It looks like AF22 was intended for important low-latency traffic (it sets the Minimize-Delay bit) and is probably a better fit for ssh interactive traffic. Note that the ssh devs probably chose AF21 over AF22 because the DSCP docs say AF22 should be dropped before AF21, implying AF21 is "more important" than AF22;</div><div><br></div><div><a href="https://en.wikipedia.org/wiki/Differentiated_services#Assured_Forwarding" target="_blank">https://en.wikipedia.org/wiki/Differentiated_services#Assured_Forwarding</a></div><div><br></div><div>However, I think the DSCP standards structure the drop-order this way to reflect that they are actually equally important (as indicated by the precedence setting of "Immediate), but high-volume traffic is more likely to need the packets during congestion. Note that AF23 which sets both Minimize-Delay AND Maximize-Throughput has an even higher drop probability, probably because that's the price you pay for asking for both high volume AND low latency.</div><div><br></div><div>The use of CS1 for ssh bulk traffic is also problematic, since it doesn't set any of the old TOS bits and thus looks "normal" to anything only looking at the old Delay/Throughput/Reliablity/Cost TOS bits. The equivalent DSCP "Priority" precedence that does set the Maximize-Throughput bit is AF11, which does seem like a better fit than CS1. Another option would be to set the Minimize-Cost bit, but that bit is not used by DSCP so there is no DSCP class with that bit set.</div><div><br></div><div>So personally I'm now using the following setting in both /etc/ssh/ssh_config and /etc/ssh/sshd_config to override the defaults.</div><div><br></div><div>IPQoS af22 af11</div><div><br></div><div>Note the client/server settings affect the traffic in each direction independently; a server without this setting will send packets with tos=0x48 (AKA AF21) to a client sending packets with tos=0x50 (AKA AF22) that does have these settings.</div><div><br></div><div>My only problem now is it seems at least one old Debian ssh package (1:6.7p1-5+deb8u8) and/or the VPS I'm using for one of my machines doesn't seem to honor the IPQoS setting and is just using tos=0x0... but that's mostly unrelated.</div><div><br></div><div><br></div><div>--</div><div><a href="mailto:abo@minkirri.apana.org.au">abo@minkirri.apana.org.au</a></div></div></div></div></div>