LARTC
[Top] [All Lists]

Re: [LARTC] Strategy for penalising IPs with too many simultaneous sessi

To: Graham Leggett <minfrin@sharp.fm>
Subject: Re: [LARTC] Strategy for penalising IPs with too many simultaneous sessions
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 3 Nov 2006 16:17:50 -0800
Cc: lartc@mailman.ds9a.nl
Delivered-to: sp-com-lists@consult.net
Delivered-to: lartc-list@securepoint.com
Delivered-to: lartc@outpost.ds9a.nl
In-reply-to: <454BDA1F.2010301@sharp.fm>
List-archive: <http://mailman.ds9a.nl/pipermail/lartc>
List-help: <mailto:lartc-request@mailman.ds9a.nl?subject=help>
List-id: "Mailinglist of the Linux Advanced Routing &amp; Traffic Control project" <lartc.mailman.ds9a.nl>
List-post: <mailto:lartc@mailman.ds9a.nl>
List-subscribe: <http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc>, <mailto:lartc-request@mailman.ds9a.nl?subject=subscribe>
List-unsubscribe: <http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc>, <mailto:lartc-request@mailman.ds9a.nl?subject=unsubscribe>
Organization: OSDL
References: <454BDA1F.2010301@sharp.fm>
Sender: lartc-bounces@mailman.ds9a.nl
On Sat, 04 Nov 2006 02:09:03 +0200
Graham Leggett <minfrin@sharp.fm> 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,

How about making a modified version of RED that works by doing:

enqueue(skb) {
      if (qlen < min) {
        skb_queue(q, skb);
        return;
      }

      if (qlen > threshold) {
        drop(skb);
        return;
      }

       skb1 = queue[random() % qlen];
       if (skb->protocol == IP && skb1->protocol == IP &&
              skb->src.ip == skb1->src.ip) {
                drop(skb);
                drop(skb1);
                return;
        }
        
        skb_enqueue(q, skb);
}

There will be issues since the queue is no longer work conserving.
But it will penalize overloaders.



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

<Prev in Thread] Current Thread [Next in Thread>