All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mohan Sundaram <mohan.tux@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Strategy for penalising IPs with too many	simultaneous
Date: Sat, 04 Nov 2006 01:50:04 +0000	[thread overview]
Message-ID: <454BEEFC.4030707@vsnl.com> (raw)
In-Reply-To: <454BDA1F.2010301@sharp.fm>

Graham Leggett wrote:
> 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
I've my misgivings with this scheme.

What you are doing makes sense only if the number of connections is a 
constrained resource. If bandwidth is the constraint, then shaping by 
source IP irrespective of number of connections will do the job. As far 
as I've seen, routers can support 200k connections and this is 
sufficient for many large LANs - say 500 node LAN with 400 connections 
per node.

In many cases, the user may not know how many connections he is opening 
or which app is consuming connections. Thus, the user may not be in a 
position to take remedial action and hence will be at a disadvantage.

I'm questioning the need for such a scheme really.

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

  parent reply	other threads:[~2006-11-04  1:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-04  0:09 [LARTC] Strategy for penalising IPs with too many simultaneous Graham Leggett
2006-11-04  0:17 ` Stephen Hemminger
2006-11-04  1:50 ` Mohan Sundaram [this message]
2006-11-04 11:14 ` Graham Leggett
2006-11-04 15:40 ` Peter Surda
2006-11-05 21:47 ` Andrew Beverley
2006-11-11 12:54 ` Andy Furniss
2006-11-11 13:42 ` Oscar Mechanic
2006-11-11 18:01 ` Jan Groenewald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=454BEEFC.4030707@vsnl.com \
    --to=mohan.tux@gmail.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.