[LARTC] Strategy for penalising IPs with too many simultaneous

From: Graham Leggett <minfrin@sharp.fm>
To: lartc@vger.kernel.org
Subject: [LARTC] Strategy for penalising IPs with too many simultaneous
Date: Sat, 04 Nov 2006 00:09:03 +0000	[thread overview]
Message-ID: <454BDA1F.2010301@sharp.fm> (raw)

Hi all,

I have been trying to investigate traffic shaping in an effort to solve 
the "unfriendly network apps" problem on a test network.

I have a basis by which I'd like to shape traffic, but studying the 
howto doesn't uncover and existing qdisc that seems to fit what I would 
like to do.

The problem I would like to address is to prevent an IP address opening 
10 simultaneous streams from drowning out another IP address that opened 
1 stream.

I would like to penalise IP addresses where two or more simultaneous 
sessions are in effect, by adding a delay to the streams such that the 
total bandwidth used by the IP address is capped at a declining curve.

In other words, assuming that the data you are sending is constrained 
behind you by a 1mbps bottleneck.

When an IP has one session detected, their traffic is passed through, 
and normal rules apply.

When an IP has two sessions detected, their combined sent traffic 
towards the IP is delayed and shaped down to say 800kbps.

When an IP has three sessions detected, their combined sent traffic 
towards the IP is delayed and shaped down to say 600kbps.

The starting point of how many sessions can be open before penalising 
takes effect, the starting point of the curve and the gradient of the 
curve would obviously be subject to lots of experimentation and would be 
set by the admin.

The nett effect I am looking for, is that a user who chooses to open 
multiple simultaneous streams, should see a noticable decrease in 
maximum throughput, in an effort to discourage them from swamping the 
network with sessions.

My question is, does a qdisc exist that implements something like this?

Is this a reasonable thing to do, or will a strategy like this not work, 
and if not, why not? (for the purposes of me better understanding the 
issues).

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