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