Per connection transfer rate matching

Per connection transfer rate matching

[Nuutti Kotivuori]

I have recently trying to find a solution to a QoS problem of sorts.

What I would wish to be able to do, is to mark a connection based on
the data transfer rate in that connection. That is, to have some sort
of a token bucket filter or rate estimator attached to a certain
connection tracking connection - and to be able to use that in
netfilter rules.

An example problem case is trivial. Let's assume we have an
interactive transfer class, which has several interactive sessions
where latency is tried to be kept to a minimum. Occasionally some
interactive session might start transferring a lot of data - in which
case it should be scheduled into the maximum throughput class,
forgetting latency, until it doesn't transfer that much and it should
be returned to the interactive class again.

The 'connbytes' match in the patch-o-matic matches on cumulative
transfer amounts on a per connection basis. The 'limit' match matches
packets on a simple token bucket implementation. Combining these two
to something which matches bytes on a simple token bucket per
connection would create the desired result.

So, does such a thing exist already? If not, do other people see this
as useful as I do? Or have I missed something crucial?

And finally, if it doesn't exist already, making such a module
shouldn't be too hard - would anyone be willing to undertake such an
ordeal?

-- Naked

Re: Per connection transfer rate matching

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Thu, 2004-02-05 at 00:31, Nuutti Kotivuori wrote:
> I have recently trying to find a solution to a QoS problem of sorts.
> 
> What I would wish to be able to do, is to mark a connection based on
> the data transfer rate in that connection. That is, to have some sort
> of a token bucket filter or rate estimator attached to a certain
> connection tracking connection - and to be able to use that in
> netfilter rules.
> 
> An example problem case is trivial. Let's assume we have an
> interactive transfer class, which has several interactive sessions
> where latency is tried to be kept to a minimum. Occasionally some
> interactive session might start transferring a lot of data - in which
> case it should be scheduled into the maximum throughput class,
> forgetting latency, until it doesn't transfer that much and it should
> be returned to the interactive class again.
> 
> The 'connbytes' match in the patch-o-matic matches on cumulative
> transfer amounts on a per connection basis. The 'limit' match matches
> packets on a simple token bucket implementation. Combining these two
> to something which matches bytes on a simple token bucket per
> connection would create the desired result.
> 
Could you not do it then by using two user defined chains, one for limit
match and one for connbytes?

> So, does such a thing exist already? If not, do other people see this
> as useful as I do? Or have I missed something crucial?
> 
> And finally, if it doesn't exist already, making such a module
> shouldn't be too hard - would anyone be willing to undertake such an
> ordeal?
> 
> -- Naked
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Per connection transfer rate matching

[Nuutti Kotivuori]

Ray Leach wrote:
> On Thu, 2004-02-05 at 00:31, Nuutti Kotivuori wrote:
>> The 'connbytes' match in the patch-o-matic matches on cumulative
>> transfer amounts on a per connection basis. The 'limit' match
>> matches packets on a simple token bucket implementation. Combining
>> these two to something which matches bytes on a simple token bucket
>> per connection would create the desired result.
>
> Could you not do it then by using two user defined chains, one for
> limit match and one for connbytes?

Nay. If you think about what I am wanting, it should be obvious that
it can't work.

Anyway, I cooked up a patch to do what I wanted - I posted it on the
netfilter-devel list just recently. It's still in development and very
basic, but seems to work fine.

-- Naked