All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadtec <vadtec@vadtec.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Question about how TC enforces bandwidth limiting
Date: Thu, 06 Sep 2007 18:43:54 +0000	[thread overview]
Message-ID: <46E04A6A.5000707@vadtec.net> (raw)
In-Reply-To: <46D758ED.2030705@vadtec.net>

David Boreham wrote:
> The advice you received is pretty good.
> Avoid ingress shaping at all costs, and
> you don't need it anyway for your situation.
>
> Use egress shaping on both your internal and
> external interfaces.
> Traffic coming IN to your network gets shaped
> as egress traffic on the LAN interface.
> Traffic going OUT from your network gets
> shaped as egress traffic on the WAN interface.
> So all shaping is egress, but you're able to
> shape in both directions by always delaying
> packets as they are SENT by your router.
>
> Think of it this way : all you can really do is
> delay sending packets (or ultimately drop them
> which is the same as infinitely delaying).
> Packets arrive when they arrive, you have no
> control over that. This is why shaping has to be
> done on egress traffic -- it's the only lever you have
> to pull on.
>
>
>
Thank you! This is the first explanation that has actually made sense to 
me. Before I had a vague idea of what was being said.

I do have one question though. On the egress shaping on eth1 (LAN 
interface), when using iptables I should do everything in the 
POSTROUTING chain correct? That way it gets routed to the proper LAN 
node and still gets shaped, correct? If thats the case, I can have a 
setup working in no time (I hope).

Many thanks,

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

  parent reply	other threads:[~2007-09-06 18:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30 23:55 [LARTC] Question about how TC enforces bandwidth limiting Vadtec
2007-09-03 12:05 ` Vadtec
2007-09-03 18:43 ` Martin A. Brown
2007-09-03 20:15 ` Vadtec
2007-09-04  2:09 ` Martin A. Brown
2007-09-04 12:27 ` Vadtec
2007-09-04 13:02 ` Martin A. Brown
2007-09-04 13:39 ` Vadtec
2007-09-06  1:13 ` Vadtec
2007-09-06  2:47 ` Martin A. Brown
2007-09-06  3:04 ` Vadtec
2007-09-06  4:08 ` Vadtec
2007-09-06 17:43 ` Vadtec
2007-09-06 17:57 ` David Boreham
2007-09-06 18:43 ` Vadtec [this message]
2007-09-06 19:32 ` David Boreham
2007-09-06 20:09 ` Vadtec
2007-09-06 20:09 ` Andy Furniss

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=46E04A6A.5000707@vadtec.net \
    --to=vadtec@vadtec.net \
    --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.