<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 10:35 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 23/04/2015 9:14 a.m., Nick Rogers wrote:<br>
> After upgrading from 3.4.x to 3.5.x, I've noticed a new error message with<br>
> my squid configuration. Apparently squid 3.5 no longer allows setting the<br>
> two lower-most ECN bits of the ToS byte.<br>
<br>
</span>Allowing it and leaving it up to admin was causing too much confusion<br>
over mysteriously dropped traffic.<br>
<br>
Attempts to bit-shift values were not backward compatible. So instead we<br>
opted to take a bitmask hex value as the TOS parameter and explicitly<br>
forbid with warning the ECN bits being set in that mask.<br></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
<br>
> I realize that this is to<br>
> encourage people to use the modernized definition of ToS being a 6 bit DSCP<br>
> field and a two bit ECN field, however enforcing this in the configuration<br>
> parser introduces a big problem for me. I use the ToS byte as a way to tag<br>
> outbound requests from squid based on ACLs, to then queue the traffic<br>
> differently via PF + ALTQ engine on FreeBSD. This is a way to queue upload<br>
> traffic from squid on a per-IP/ACL basis. Having 256 values (8 bit ToS) to<br>
> work with is a lot preferable than only 64 (6 bit DSCP field). I'm not sure<br>
> if I care if the ECN bits are set, as it is likely scrubbed away by my<br>
> upstream ISP,<br>
<br>
</span>ECN is an end-to-end property of the packets. It does not get scrubbed<br>
away. Your ISP probably uses MPLS these days, so these packets existing<br>
your network with ECN set cause your network to be marked as a congested<br>
zone - any packets going from another congested network to yours get<br>
*dropped* until the congestion in one of the networks gets resolved. It<br>
can also trigger nasty actions such as TCP throttling on the other end<br>
of the connection.<br></blockquote><div><br></div><div>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 "<span class="">net.inet.tcp.</span><span class="">ecn</span><span class="">.enable" sysctl set to 0. </span>I guess this assumption is wrong? Thanks for clarifying.</div>







<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
NP: Do you find your ISP service is "a little shitty" with packet loss<br>
and traffic slowing down occasionally? ECN and/or ICMP congestion<br>
control breakage is often the cause. Could be self-inflicted.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
<br>
> or I can normalize it with PF. The point is I really need to<br>
> be able to tag outgoing packets with the full 8 bits of the ToS byte, not<br>
> just 6. I've been doing this for nearly a decade since early squid 2.x.<br>
><br>
> So my question is, is the squid team willing to revert this change<br>
> entirely, and leave it up to the admin to decide what ToS values are<br>
> appropriate. Or are you guys now pretty adamant about never setting the ECN<br>
> field?<br>
<br>
</span>ECN is pretty standard these days. Any casual update or upgrade to the<br>
machine software, hardware, or configuration anywhere in the network(s)<br>
it communicates over could result in unwanted traffic loss or worse<br>
behaviour.<br>
<br>
If you are in the practice of using those bits in the TOS value you are<br>
of course free to patch the mask removal yourself, but we wont be<br>
publishing new versions of Squid that touch the ECN bits - ie. not while<br>
IPv4 is still in wide use.<br></blockquote><div><br></div><div>I understand the reasoning now. Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
IPv6 handles DSCP+ECN better and is artificially limited by this. But we<br>
feel that is justified temporarily to avoid confusion and problems when<br>
mapping DSCP between IPv4 and IPv6 traffic.<br>
<span class=""><br>
<br>
><br>
> It looks like the change got snuck into this commit along with fixing some<br>
> other tcp outgoing tos bugs. It really caught me off-guard because there is<br>
> no mention of this new behavior in the changelog.<br>
><br>
> <a href="https://github.com/squid-cache/squid/commit/651ba437462fb5fde21f8d3b66d09afa1e069d5c" target="_blank">https://github.com/squid-cache/squid/commit/651ba437462fb5fde21f8d3b66d09afa1e069d5c</a><br>
><br>
<br>
</span>The TOS directives have always been documented as being for the<br>
DiffServ/DSCP values. The only reason they ever allowed those ECN bits<br>
to be set in the first place is that they pre-date ECNs existence.<br>
<br>
Sorry that we missed out the documentation update mentioning that<br>
change. A note is going in now.<br>
<span class=""><br>
<br>
> The enforcement happens in src/cache_cf.cc. Its 5 lines of code that seem<br>
> trivial to either remove or make configurable, however I am not sure how to<br>
> go about making it configurable. I am debating just patching my squid<br>
> builds to remove the check against the ToS field, but I would like to use<br>
> unmodified squid 3.5.x. I'm not sure if going from 256 to 64 possible<br>
> fields is possible for my deployments.<br>
<br>
</span>It better be. Any software not supporting ECN will have problems<br>
operating over VPN, IPSEC or MLPS.<br></blockquote><div><br></div><div>So to clarify, squid is implicitly ECN capable, but manually overriding the ECN field via tcp_outgoing_tos was causing problems?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
NOTE: We have the NETMASK feature made available on Linux now for<br>
systems that need large numbers of packet flow tag values within the<br>
local machine. I'm not aware of any equivalent on non-Linux systems, but<br>
if they exist in PF (other than setting the TOS bits) then we are open<br>
to supporting that.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks for your feedback.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Amos<br>
<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div><br></div></div>