Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Jason Boxman <jasonb@edseek.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Prioritizing forwarded traffic over locally generated traffic
Date: Thu, 23 Sep 2004 22:34:56 +0000	[thread overview]
Message-ID: <200409231834.56880.jasonb@edseek.com> (raw)
In-Reply-To: <20040923220934.TUOJ19539.mta07-svc.ntlworld.com@slartibartfast>

On Thursday 23 September 2004 18:09, Neil Greatorex wrote:
> Hi,
>
> I'm a complete newbie at this traffic shaping / QoS stuff so please excuse
> me if this is a silly question. I've searched and searched on Google and I
> just end up confusing myself even more, so I thought I'd post my question
> to this list and see whether someone can help me!

Sure.

> Basically, I am running a Linux box as a NAT router on my home network
> (machine name marvin). I want to use mldonkey on the router box for P2P
> downloads. What I wish to do, is to have any traffic that originates on the
> internal LAN take priority over traffic that is generated from mldonkey on
> marvin. I don't wish to restrict the maximum bandwidth for the P2P
> downloads on a permanent basis if I can help it - so that all the bandwidth
> is used all of the time.

So you'd like to classify p2p traffic from mldonkey (Overnet/Kad/eDonkey) such 
that it is granted a lower priority than other traffic?  Not a problem.  
However, because those three protocols use random ports, you cannot classify 
'edonkey' traffic based on port.  You can use either ipp2p or L7-Filter to 
match these flows based on layer 7 pattern matching, though.

> My plan was to use the PREROUTING and OUTPUT chains of the mangle table to
> mark the packets, and then use some form of qdisc/class structure that will
> prioritise one over the other.

I believe you can use the POSTROUTING chain of the mangle table and nab all 
traffic.  L7-Filter has a nice graphic[1] available.

[1] http://l7-filter.sourceforge.net/PacketFlow.png

> The aim of this is to have an upload that would normally take say 20
> seconds from a machine on the LAN still take 20 seconds when mldonkey is
> uploading - so the NAT traffic will take all the bandwidth away from
> mldonkey. The closer to this aim I can get the better!

That makes sense, although the time interval is relative to the data size and 
protocol being used, so it isn't a useful measure for the rest of us.  What's 
the link size?  What's the file / data size?

> To test implementations, I am using SFTP to upload a file from both a
> machine on my internal network (named slartibartfast), and marvin (the
> router machine) simultaneously. The perfect behaviour would be for the
> upload on slartibartfast to take 20 seconds, and the upload on marvin to
> take 40.

Which implementations have you tried to use?  I'd imagine Wondershaper?  
Others?

> I have tried various setups of qdiscs and classes, using various examples
> from all over the web (including the LARTC FAQ/cookbook) but I haven't been
> able to get anywhere near my aim. All of the attempts I've made have led to
> both uploads taking near enough 40 seconds, as they are both running at 50%
> of the available bandwidth. I would like it to give almost all the
> bandwidth to slartibartfast for the first 20 seconds, and then all the
> bandwidth to marvin for the remaining time.

The problem is likely that you cannot effectively match p2p flows that use the 
'edonkey' protocols.  (Actually, the latest L7-Filter pattern matches do not 
yet match eMule's new Kad network, so you'll still need to either disable 
support for that in mldonkey or deal with latency issues that arise.)

> I would really appreciate it if someone could tell me whether:
> a) This setup is actually possible!

Absolutely!

> b) If using the mangle table chains is correct for this

I believe so.

> c) If it is, the easiest/best/fastest way to implement it. Just some hints
> for the right direction would be fine!

You might explore my guide[2].  I have a setup quite similar to the one you 
wish to implement, except on my router does not generate any traffic.  (I 
have mldonkey running on an internal machine instead.)

[2] http://trekweb.com/~jasonb/articles/traffic_shaping/

> Many thanks in advance,
> Neil Greatorex
>

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

  reply	other threads:[~2004-09-23 22:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-23 22:09 [LARTC] Prioritizing forwarded traffic over locally generated traffic Neil Greatorex
2004-09-23 22:34 ` Jason Boxman [this message]
2004-09-24  5:35 ` [LARTC] Prioritizing forwarded traffic over locally generated kraquen
2004-09-24 16:55 ` [LARTC] Prioritizing forwarded traffic over locally generated traffic Neil Greatorex
2004-09-24 17:07 ` Jason Boxman
2004-10-07  3:50 ` Alexander Samad

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=200409231834.56880.jasonb@edseek.com \
    --to=jasonb@edseek.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