Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Weird quirk with ingress policing
Date: Tue, 16 Mar 2004 00:34:01 +0000	[thread overview]
Message-ID: <40564B79.7030300@dsl.pipex.com> (raw)
In-Reply-To: <40543DD1.5020702@rebirthing.co.nz>

David McNab wrote:
> Hi,
> 
> I notice that if two or more existing connections match an ingress 
> policing filter, the input bandwidth does not get evenly divided up 
> between the n connections.
> 
> Kinda like litters of baby animals, where the stronger babies get more 
> access to the mothers teats and grow up bigger and faster than their 
> siblings.

That's tcp not being fair.

> 
> The only workaround that's working for me is to set explicit ingress 
> policing filters, which match src and dest host and port, so for each 
> filter there can only be exactly one connection which matches. Then, 
> it's just a matter of evenly dividing up the allocated total input bw 
> amongst these n processes. This works, but it's not exactly optimal.
> 

Ingress shaping is alot harder than egress. It is possible to use 
htb/sfq for ingress by either shaping outbound on your LAN interface (if 
you have only one) or by using IMQ on your WAN interface. I found this 
nicer than using an ingress policer, but it's not perfect.

In reality if you want to properly shape ingress from behind the 
bottleneck you need something to keep state on all the TCP connections, 
have the ability to change the advertised window to control them and to 
be aware of what unstoppable packets are due in the future from the WAN 
so that new TCP connections can be started without causing your queues 
to move into your ISPs buffer. Even if you did that you are still up 
against bursty delivery of packets and occilations of TCP caused for 
example, by ack compression.

Andy.




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

      parent reply	other threads:[~2004-03-16  0:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-14 11:11 [LARTC] Weird quirk with ingress policing David McNab
2004-03-14 18:33 ` Roy
2004-03-14 22:51 ` David McNab
2004-03-16  0:34 ` Andy Furniss [this message]

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=40564B79.7030300@dsl.pipex.com \
    --to=andy.furniss@dsl.pipex.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox