Re: [squid-users] question about setting TOS for specific media types

Hi, I applied the patch but it doesn’t seem to be working. I did a bit of other testing. I read the bug report and saw that the regression was in 3.1.12, so I tried 3.1.11 and also saw poor results (it actually seemed as if the occasional packet would have tos set, but not most). For testing I was telling squid to tag all packets so I could be pretty certain nothing was misconfigured.

I then compiled 3.0 stable 26, and it has worked flawlessly all day, tagging client packets that matched a dstdom_regex acl.

Thanks,
Brian

On Mar 22, 2012, at 11:45 PM, Amos Jeffries wrote:

> On 21/03/2012 10:19 a.m., Brian Landy wrote:
>> On Mar 20, 2012, at 10:20 AM, Amos Jeffries wrote:
>>
>>> On 21/03/2012 2:26 a.m., Brian Landy wrote:
>>>> Hi, I was hoping to use traffic shaping to reserve bandwidth for http streaming video, and use squid to tag the video traffic separately from other content. I am running OpenBSD 5.0 with squid 2.7, using squid as a transparent non-caching proxy. I am attempting to get squid to set the TOS on the packets from server to client so pf can assign them to an appropriate queue (outbound on the internal interface).
>>>> So I tried something like this:
>>>>
>>>> acl webvideo rep_mime_type -i ^video/MP2T$
>>>> acl webvideo rep_mime_type -i ^video/mp4$
>>>> tcp_outgoing_tos 0x15 webvideo
>>>>
>>>> However, as best I can tell squid is not setting the tos on any of these packets. Have I overlooked something? (the 0x15 was picked at random) I verified I have the rep_mime_types defined properly by setting “http_reply_access deny webvideo” and the content was blocked.
>>> You overlooked that outgoing TOS is on the request from Squid to the server. Squid does not have any reply yet.
>>>
>>> You need to find some request-based way to predict what type of reply will come back. I would think a few false positives would be fine so you can probably base it on the domain name or a URL file-extension pattern. Squid ACLs have full access to any header content though, there may be something better buried in there.
>>>> Also, to validate that squid was able to set TOS at all, I tried this:
>>>>
>>>> acl all src all
>>>> tcp_outgoing_tos 0x15 all
>>>>
>>>> In this case I see the tos set on the packets to the server, but not set on the packets back to the client (which I believe I need set in order to assign the streaming content to the appropriate queue on the inside interface).
>>> There is a clientside_tos in Squid-3 series for the packets going from Squid to client.
>>>
>>>> Any advice on what I am doing wrong, or whether squid is even the correct approach for this, is greatly appreciated. Thanks!
>>> You need to upgrade to squid-3. Preferrably the current supported release (3.1.19 as of this writing).
>>>
>>>
>>> Amos
>> Thanks, I’ve installed 3.1.19 and have been giving it a try. It seems like clientside_tos is exactly what I want.
>>
>> However, I have been unable to get it to work on some simple examples:
>>
>> acl myhost 192.168.0.1
>> http_access allow myhost
>> clientside_tos 0x15 myhost
>>
>> or
>>
>> acl d_any all
>> http_access allow d_any
>> clientside_tos 0x15 any
>>
>> or
>>
>> clientside_tos 0x15 all
>>
>> When I inspect the packets returned from the proxy to the client, tos is not set. Any thoughts?
>>
>> And to clarify, matching rep_mime_type won’t work for this, in conjunction with clientside_tos, even though it inspects the reply?
>
> Sorry, mea culpa, this is http://bugs.squid-cache.org/show_bug.cgi?id=3504
>
> You can find the patch at http://master.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10444.patch
>
> If there are any problems with it please let me know asap.
>
> Amos
Received on Mon Mar 26 2012 - 01:54:22 MDT