Re: [squid-users] TOS from remote to squid(2 series)

From: Hasanen AL-Bana <hasanen_at_gmail.com>
Date: Sat, 23 Apr 2011 16:34:19 +0300

it might worth trying to change few bits in the source code and
implement this feature. I thought about adding 'tos' field to squid
reply_header structure and read this value from source. However ,
squid doesn't deal with packets, it deals with HTTP requests/replies.
in our case ,how do you guarantee that all packets through current
connection hold the same TOS ? Is it possible for squid the inspect
all packets ? I don't think so.

On Sat, Apr 23, 2011 at 4:24 PM, jiluspo <jiluspo_at_smartbro.net> wrote:
>> On Sat, 2011-04-23 at 20:36 +0800, jiluspo wrote:
>>>
>>> remote servers I mean http web servers TOS.
>>> I already know about peers in fact current squid(as of 04/24/11) TOS are
>>> not
>>> being marked peer(digest or icp) hit when local miss.
>>> http://bugs.squid-cache.org/show_bug.cgi?id=3202
>>>
>>> AFAIK squid 2 series TOS always marked zero from remote servers.
>>> according to source code initial tos=0;
>>>
>>> there are some patches called preserve tos miss but kernel(linux) needs
>>> to
>>> be patched.
>>>
>>> does kernel really need to patch in order to pass the TOS value from
>>> kernel
>>> to squid?
>>>
>>
>> Yes, I'm afraid it does, due to the way the networking stack works.
>>
>> If you want *similar* functionality *without* patching the kernel, then
>> you can use the "qos_flows mark" feature, which uses the netfilter mark
>> value rather than the TOS value. However, marks do not apply remotely,
>> so this will only work to retain marks on the local machine.
>
> therefore squid 3.2 still cant preserve TOS value from remote server to
> clients.
> hmn. what about the zph that requires kernel patch? would it work with
> remote servers?
>
> lastly, what about its performance degradation(req/sec and service time) if
> we add this feature.
> has anyone run some benchmarks if with/without mark.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
Received on Sat Apr 23 2011 - 13:34:45 MDT

This archive was generated by hypermail 2.2.0 : Sat Apr 23 2011 - 12:00:04 MDT