[squid-users] WARNING: Tos value ... adjusted

[Amos Jeffries]

On 23/04/2015 9:14 a.m., Nick Rogers wrote:
> After upgrading from 3.4.x to 3.5.x, I've noticed a new error message with
> my squid configuration. Apparently squid 3.5 no longer allows setting the
> two lower-most ECN bits of the ToS byte.

Allowing it and leaving it up to admin was causing too much confusion
over mysteriously dropped traffic.

Attempts to bit-shift values were not backward compatible. So instead we
opted to take a bitmask hex value as the TOS parameter and explicitly
forbid with warning the ECN bits being set in that mask.


> I realize that this is to
> encourage people to use the modernized definition of ToS being a 6 bit DSCP
> field and a two bit ECN field, however enforcing this in the configuration
> parser introduces a big problem for me. I use the ToS byte as a way to tag
> outbound requests from squid based on ACLs, to then queue the traffic
> differently via PF + ALTQ engine on FreeBSD. This is a way to queue upload
> traffic from squid on a per-IP/ACL basis. Having 256 values (8 bit ToS) to
> work with is a lot preferable than only 64 (6 bit DSCP field). I'm not sure
> if I care if the ECN bits are set, as it is likely scrubbed away by my
> upstream ISP,

ECN is an end-to-end property of the packets. It does not get scrubbed
away. Your ISP probably uses MPLS these days, so these packets existing
your network with ECN set cause your network to be marked as a congested
zone - any packets going from another congested network to yours get
*dropped* until the congestion in one of the networks gets resolved. It
can also trigger nasty actions such as TCP throttling on the other end
of the connection.

NP: Do you find your ISP service is "a little shitty" with packet loss
and traffic slowing down occasionally? ECN and/or ICMP congestion
control breakage is often the cause. Could be self-inflicted.


> or I can normalize it with PF. The point is I really need to
> be able to tag outgoing packets with the full 8 bits of the ToS byte, not
> just 6. I've been doing this for nearly a decade since early squid 2.x.
> 
> So my question is, is the squid team willing to revert this change
> entirely, and leave it up to the admin to decide what ToS values are
> appropriate. Or are you guys now pretty adamant about never setting the ECN
> field?

ECN is pretty standard these days. Any casual update or upgrade to the
machine software, hardware, or configuration anywhere in the network(s)
it communicates over could result in unwanted traffic loss or worse
behaviour.

If you are in the practice of using those bits in the TOS value you are
of course free to patch the mask removal yourself, but we wont be
publishing new versions of Squid that touch the ECN bits - ie. not while
IPv4 is still in wide use.

IPv6 handles DSCP+ECN better and is artificially limited by this. But we
feel that is justified temporarily to avoid confusion and problems when
mapping DSCP between IPv4 and IPv6 traffic.


> 
> It looks like the change got snuck into this commit along with fixing some
> other tcp outgoing tos bugs. It really caught me off-guard because there is
> no mention of this new behavior in the changelog.
> 
> https://github.com/squid-cache/squid/commit/651ba437462fb5fde21f8d3b66d09afa1e069d5c
> 

The TOS directives have always been documented as being for the
DiffServ/DSCP values. The only reason they ever allowed those ECN bits
to be set in the first place is that they pre-date ECNs existence.

Sorry that we missed out the documentation update mentioning that
change. A note is going in now.


> The enforcement happens in src/cache_cf.cc. Its 5 lines of code that seem
> trivial to either remove or make configurable, however I am not sure how to
> go about making it configurable. I am debating just patching my squid
> builds to remove the check against the ToS field, but I would like to use
> unmodified squid 3.5.x. I'm not sure if going from 256 to 64 possible
> fields is possible for my deployments.

It better be. Any software not supporting ECN will have problems
operating over VPN, IPSEC or MLPS.

NOTE: We have the NETMASK feature made available on Linux now for
systems that need large numbers of packet flow tag values within the
local machine. I'm not aware of any equivalent on non-Linux systems, but
if they exist in PF (other than setting the TOS bits) then we are open
to supporting that.

Amos