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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
