LARTC - Oct 2005 - Differentiating between http downloads and interactive traffic

Hi,

 

I''ve been wondering if anyone has thought of a way to differentiate
between an established http download and interactive http traffic?  I
would like to give interactive http traffic priority over someone
downloading large files.  

 

Has anyone any ideas how to detect packets that are part of a download
like this?

 

Thanks.



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

I don''t know how you really can differ between them. But I guess easy 
way would be using HTB burst.
So the first (small?) packets get a high bandwidth immediately trough 
burst settings. If more data is requested,
it will be slown down to defined ceil bandwidth.

Cheers,
Andreas

Paul J. Smith wrote:
> Hi,
>
> I’ve been wondering if anyone has thought of a way to differentiate 
> between an established http download and interactive http traffic? I 
> would like to give interactive http traffic priority over someone 
> downloading large files.
>
> Has anyone any ideas how to detect packets that are part of a download 
> like this?
>
> Thanks.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>LARTC mailing list
>LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>  
>

On Sat, 22 Oct 2005 10:17:56 +0100
"Paul J. Smith" <pjsmith@mtgsy.net> wrote:
> I''ve been wondering if anyone has thought of a way to
differentiate
> between an established http download and interactive http traffic?  I
> would like to give interactive http traffic priority over someone
> downloading large files.  
Hello,

you may give the "connbytes" Netfilter extension a try. With that
extension, you can mark those TCP connections which have transmitted a
certain number of bytes. Then you can use the fwmark QoS filter to
differentiate them. (The drawback is that someone can bypass it with
closing the connection after the limit, and resuming the download with
another connection.)

Currenty connbytes is in the extra section, so you must patch the kernel
(and possibly iptables) to use it.

Alternatively, you can use delay pool feature of the Squid HTTP proxy,
which does almost the same on application level.


norbi

I would recommend looking at the connrate
(http://www.netfilter.org/projects/patch-o-matic/pom-extra.html#pom-extra-connrate)
Patch-O-Matic patch.  Your interactive sessions could be long lived and thus
pass the connlimit and / or connbytes matches and thus be falsely classified. 
Where as if you test for your interactive sessions by looking for an over all
average low rate, burst delay burst delay etc, you should have a low average and
thus be able to match based on rate to classify them higher.



Grant. . . .

Paul J. Smith wrote:
> Hi,
> 
> I’ve been wondering if anyone has thought of a way to differentiate 
> between an established http download and interactive http traffic?  I 
> would like to give interactive http traffic priority over someone 
> downloading large files. 
> 
> Has anyone any ideas how to detect packets that are part of a download 
> like this?
> 
> Thanks.

Hi,

I''ve read your recomendation:

(http://www.netfilter.org/projects/patch-o-matic/pom-extra.html#pom-extra-co
nnrate

in order to differentiate between an established http download
and interactive http traffic.

In that patch suggest something  like that:


iptables .. -m tos --tos Minimize-Delay \
            -m connrate --connrate 20000:inf \
            -j TOS --set-tos Maximize-Throughput

 => match packets in minimize-delay TOS connections that are transferring
    faster than 20kbps and change their tos to maximize-throughput instead.

Is very intresting!

Somebody has really tryed this patch ?

best regards

andres



->
->
-> I would recommend looking at the connrate
-> (http://www.netfilter.org/projects/patch-o-matic/pom-extra.html#p
-> om-extra-connrate) Patch-O-Matic patch.  Your interactive
-> sessions could be long lived and thus pass the connlimit and /
-> or connbytes matches and thus be falsely classified.  Where as
-> if you test for your interactive sessions by looking for an over
-> all average low rate, burst delay burst delay etc, you should
-> have a low average and thus be able to match based on rate to
-> classify them higher.
->
->
->
-> Grant. . . .
->
-> Paul J. Smith wrote:
-> > Hi,
-> >
-> > I’ve been wondering if anyone has thought of a way to differentiate
-> > between an established http download and interactive http traffic?  I
-> > would like to give interactive http traffic priority over someone
-> > downloading large files.
-> >
-> > Has anyone any ideas how to detect packets that are part of a
download
-> > like this?
-> >
-> > Thanks.
->
-> _______________________________________________
-> LARTC mailing list
-> LARTC@mailman.ds9a.nl
-> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc