All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Stark <gsstark@mit.edu>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: Shaping incoming traffic on the other interface
Date: Thu, 10 Jun 2004 20:07:16 +0000	[thread overview]
Message-ID: <87oenrtbwr.fsf@stark.xeocode.com> (raw)
In-Reply-To: <87u0xjtma8.fsf@stark.xeocode.com>


Matteo Brusa <miagi@tiscali.it> writes:

> tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
> tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

I'm using sfq as well. But I'm wondering if I wouldn't be better off with
pfifo with a short queue. One of the entries in the HTB faq suggests using sfq
can make it hard to limit bandwidth precisely because it requires enough
memory that tcp_wmem kicks in. Or is that only for locally generated traffic?

> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10
> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
> 
> The packets are marked in the POSTROUTING chain of the mangle table, as usual.
> I'm running kernel 2.4.20-30.9 custom and iptables v1.2.7a. HTB is reported as 3.10.
> Note that the problem raises when i hit the ceil throuput.

I'm still unsure whether I want to be using iptables to mark packets or stick
with the tc filters I inherited from wshaper.

Marking packets in iptables has the advantage that it knows which packets were
natted and what the host on the far side of the NAT is. It also has some more
flexible methods for matching.

One thing I'm wondering, is it possible in iptables to mark all packets after
some amount of traffic? Like, for example I want port 80 traffic to be higher
priority than ftp-data and bittorrent, but only for regular browsing. If I
download something over, say, 200k I want to to get downgraded to the same
group as ftp-data and bittorrent. Also, bittorrent has a habit of occasionally
using random ports and doesn't set TOS. So if iptables knew that that flow had
already transfered more than some threshold of data it could downgrade it.

Actually another possibility is any flow open for more than, say, 30s could be
downgraded.

I don't think the qdiscs handle things at this granularity, but iptables sure
does. I don't recall seeing any of these features but it doesn't seem like it
would be much of a stretch for it.

-- 
greg

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

  parent reply	other threads:[~2004-06-10 20:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-10 16:23 [LARTC] Re: Shaping incoming traffic on the other interface Greg Stark
2004-06-10 16:54 ` Matteo Brusa
2004-06-10 20:07 ` Greg Stark [this message]
2004-06-10 20:30 ` Jason Boxman
2004-06-10 20:33 ` Andreas Klauer
2004-06-11  5:13 ` Greg Stark

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=87oenrtbwr.fsf@stark.xeocode.com \
    --to=gsstark@mit.edu \
    --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.