netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* traffic shaping with NAT: IFB as IMQ replacement?
@ 2007-03-28 16:54 Jens Thiele
  2007-03-29 16:11 ` jamal
  0 siblings, 1 reply; 4+ messages in thread
From: Jens Thiele @ 2007-03-28 16:54 UTC (permalink / raw)
  To: netdev; +Cc: lartc, Jamal Hadi Salim, linuximq

Hello,

Sorry for the many Ccs, but I hope to reach all parties involved.
I want to do traffic shaping with NAT and I wanted to do it with IFB
instead of IMQ [1]. I tried a lot of things but now I am stuck (and
maybe confused).

The setup:
               eth0             eth1
WAN/(Internet) <-> Linux Router <-> LAN

Linux router:
- does NAT for the LANs
- runs local processes communicating with the WAN/Internet

Incoming and outgoing traffic on eth0 should be subject to "traffic
shaping". I put quotes here, because it seems the term policing would
be used for the incoming traffic directed at the router itself. It is
not an ideal solution to drop incoming packets, but assuming TCP,
intelligent dropping ("shaping") is still much better than plain rate
limiting or no action at all. (see also parts of [2]). If there is a
better solution than "ingress shaping" available or being worked on,
please tell me.

First of all: Why is it difficult?
Because you can't use the advanced qdics (htb, cbq, ...) on ingres
directly (only the ingress "qdisc").

Using IMQ it is quite straightforward to work around this limitation.

It seems IFB is intented as IMQ replacement [3]

I managed to use IFB as IMQ replacement in a setup without NAT.
But when NAT is involved I am in trouble because when I want to classify
the packets they still have the translated addresses. I could live with
the translated addresses if I could use netfilter connection tracking
information to classify the packets [4]. This was also discussed in the
thread [3]:

Jamal Hadi Salim writes:
> [...] Instead the plan is to have a contrack related action. This
> action will selectively either query/create contrack state on incoming packets.
> Packets could then be redirected to dummy based on what happens -> eg 
> on incoming packets; if we find they are of known state we could send to
> a different queue than one which didnt have existing state. This
> all however is dependent on whatever rules the admin enters. [...] "


I tried something like:
tc filter add dev ... match all ... \
   action ipt -j CONNMARK --restore-mark \
   action ipt -j LOG --log-prefix "..." \
   action continue
tc filter add dev ... handle <some-mark> \
   action ipt -j LOG --log-prefix "..."

to no avail. I couldn't find any information whether this is possible
now or what steps it would take to implement this?

Greetings
Jens

PS:
similar threads on the LARTC mailing list:
http://thread.gmane.org/gmane.linux.network.routing/25922
http://www.spinics.net/lists/lartc/msg19965.html
(many more)

[1] IMQ: http://www.linuximq.net/
[2] "shaping": http://mailman.ds9a.nl/pipermail/lartc/2004q3/013093.html
[3] IFB: netdev mailing list thread "dummy as IMQ replacement"
    Message-Id: 1107123123.8021.80.camel@jzny.localdomain
    http://marc.info/?l=linux-netdev&m=110712327422706&w=2

[4] Note: I think using the old policer [Symbol: NET_CLS_POLICE [=n] Prompt: Traffic
Policing (obsolete)] this maybe works? It seems ingress policing happens
after netfilter PREROUTING if you use NET_CLS_POLICE but using
NET_CLS_ACT it happens before netfilter PREROUTING?
(see also: sch_ingress.c and
http://mailman.ds9a.nl/pipermail/lartc/2005q4/017782.html)
But then again it is marked as obsolete and I need NET_CLS_ACT to
redirect to the IFB?!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: traffic shaping with NAT: IFB as IMQ replacement?
  2007-03-28 16:54 traffic shaping with NAT: IFB as IMQ replacement? Jens Thiele
@ 2007-03-29 16:11 ` jamal
  2007-03-29 23:08   ` Gerd v. Egidy
  0 siblings, 1 reply; 4+ messages in thread
From: jamal @ 2007-03-29 16:11 UTC (permalink / raw)
  To: Jens Thiele; +Cc: netdev, linuximq

On Wed, 2007-28-03 at 18:54 +0200, Jens Thiele wrote:
> Hello,
> 
> Sorry for the many Ccs, but I hope to reach all parties involved.
> I want to do traffic shaping with NAT and I wanted to do it with IFB
> instead of IMQ [1]. I tried a lot of things but now I am stuck (and
> maybe confused).
> 
> The setup:
>                eth0             eth1
> WAN/(Internet) <-> Linux Router <-> LAN
> 
> Linux router:
> - does NAT for the LANs
> - runs local processes communicating with the WAN/Internet
> 

I understand this requirement; unfortunately when i polled for features
majority of people who emailed back were asking for the other things.
I have changed my opinion a little since last time because the
netfilter/contracking code now does netlink. I believe this could all be
achieved in user space. Infact i have started writting some code - the
problem is my time has become intermittent.
If i can get someone who can work with me to complete the work, I will
be more than happy to get that last bastion of IMQ done.
So if you are a fireman willing to be a hero (I guess all firemen want
to be heroes, why else would they be firemen?) email me privately and we
can get this done.

cheers,
jamal

PS:- i have removed lartc from the list because it bounces my emails and
i refuse to subscribe.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: traffic shaping with NAT: IFB as IMQ replacement?
  2007-03-29 16:11 ` jamal
@ 2007-03-29 23:08   ` Gerd v. Egidy
  2007-03-30 12:33     ` jamal
  0 siblings, 1 reply; 4+ messages in thread
From: Gerd v. Egidy @ 2007-03-29 23:08 UTC (permalink / raw)
  To: hadi; +Cc: Jens Thiele, netdev, linuximq

Hi,

> > Linux router:
> > - does NAT for the LANs
> > - runs local processes communicating with the WAN/Internet
>
> I understand this requirement; unfortunately when i polled for features
> majority of people who emailed back were asking for the other things.
> I have changed my opinion a little since last time because the
> netfilter/contracking code now does netlink. I believe this could all be
> achieved in user space. Infact i have started writting some code - the

I'm also interested in shaping NAT. Would you mind telling us what you have in 
mind with your userspace code? Do you plan something like

tun -> your userspace code -> tun
             ^
             | (netlink)
             v
          conntrack

Kind regards,

Gerd

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: traffic shaping with NAT: IFB as IMQ replacement?
  2007-03-29 23:08   ` Gerd v. Egidy
@ 2007-03-30 12:33     ` jamal
  0 siblings, 0 replies; 4+ messages in thread
From: jamal @ 2007-03-30 12:33 UTC (permalink / raw)
  To: Gerd v. Egidy; +Cc: Jens Thiele, netdev, linuximq

On Fri, 2007-30-03 at 01:08 +0200, Gerd v. Egidy wrote:

> I'm also interested in shaping NAT. Would you mind telling us what you have in 
> mind with your userspace code? Do you plan something like
> 
> tun -> your userspace code -> tun
>              ^
>              | (netlink)
>              v
>           conntrack
> 

Conntrack is already a perfomance hog - so using user space in that
manner is sinful. The idea is to use contrack netlink to setup tc
rules with ifb. 
In any case, if you are interested talk to me privately;
i have received a few emails since i posted but mostly for people who
want to test.  If you are in that category please just keep pinging me
and i will feel guilty and get it done.

cheers,
jamal


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-03-30 12:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-28 16:54 traffic shaping with NAT: IFB as IMQ replacement? Jens Thiele
2007-03-29 16:11 ` jamal
2007-03-29 23:08   ` Gerd v. Egidy
2007-03-30 12:33     ` jamal

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).