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

Thu Apr 23 18:26:40 UTC 2015

On Wed, Apr 22, 2015 at 10:35 PM, Amos Jeffries <squid3 at treenet.co.nz>
wrote:

> 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.
>

Can you elaborate on how you would bit-shift the values to still use the
ECN field and not cause mysterious problems. For example, using ECN bits of
00 and 11, but not 01 or 10?

>
> > 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.
>

My understanding was something else has to happen in my TCP config for ECN
to have an effect, not simply just setting the field in the packet. For
example, in FreeBSD I have the "net.inet.tcp.ecn.enable" sysctl set to 0. I
guess this assumption is wrong? Thanks for clarifying.

>
> 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.
>

I haven't noticed this explicitly, as I have a few hundred deployments, all
with different ISPs, but that is not to say its not happening.

>
> > 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.
>

I understand the reasoning now. Thanks.

>
> 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.
>

So to clarify, squid is implicitly ECN capable, but manually overriding the
ECN field via tcp_outgoing_tos was causing problems?

> 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.
>

Yeah, I've looked into that before. Unfortunately there is nothing like
that in FreeBSD that is supported by PF that I am aware of.

Thanks for your feedback.

Amos
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150423/225febc3/attachment.html>