On Wed, Apr 22, 2015 at 10:35 PM, Amos Jeffries <squ...@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@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
