All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: hadi@cyberus.ca
Cc: netdev@oss.sgi.com
Subject: Re: IMQ / new Dummy device post.
Date: Sat, 17 Apr 2004 22:56:52 +0100	[thread overview]
Message-ID: <4081A824.5020107@dsl.pipex.com> (raw)
In-Reply-To: <1082203795.1043.18.camel@jzny.localdomain>

jamal wrote:
> On Sat, 2004-04-17 at 06:39, Andy Furniss wrote:
> 
> 
>>>No i dont plan to. Why do you want to go that path?
>>
>>I think it's the only way I can shape/share my ingress traffic between a 
>>  process (eg. bittorrent/squid) running on my shaping machine and 
>>traffic that is forwarded to my LAN. I masquerade onto one real dynamic IP.
> 
> 
> I think i am almost understanding you now. Your main concern is people
> using bittorrent to upload to you, correct? 
> Is there a way to recognize packets going to/from bittorent?

Quite possibly (though I think it uses connmark which I can't use as I 
use connbytes to get new tcps out of slowstart).

I also sometimes use wget and I've seen posts on LARTC from people who 
use squid and need to solve the same problem.

> 
> 
>>In the case of pre nat outbound - I know people can mark pre NAT and 
>>shape on that, but it would allow people with big LANs doing NAT to use 
>>WRR/ESFQ on src for egress traffic.
> 
> 
> Dont jump into the HOW; lets get to your setup and dissect it. Like i
> said, dont think in terms of IMQ but still think in terms of meeting
> your requirements.
> Your setup is certainly new to me (at least from what i have been told 
> or read on how people use IMQ) - so thanks for posting. This is the kind
> of thing i needed to hear about.
> 
> 
>>My setup is very simple - the only reason I use IMQ+NAT patch is because 
>>I want to use my gateway/shaping PC to run bittorrent and I want the LAN 
>>machines to have priority/fair share of incoming traffic. I guess my 
>>setup is not that common - more common are people who run squid on the 
>>same PC they shape/do NAT on.
>>
>>ppp0 one dynamic real IP ->  gateway PC -> eth0 -> LAN 192.168.0.0/24
>>                                   |
>>                                    -> local process.
> 
> 
> 
> Ok good. Assuming you have attached your HTB etc on one or more dummy
> devices.
> 
> - packets from local Lan can be marked at ingress and redirect to a
> dummy if needed. Infact you can do this on the egress at ppp0 as well
> using the new tc -i <inputdev> that i introduced. So this is easy.
> 
> - packets from the bittorent process can be marked by iptables before
> they get NATed (is this right?). Such packets can then be redirected to
> dummy from egress of ppp0 using fw classifier. So again this is easy.

Yes - egress is sortable without IMQ.

> 
> - The third path is packets that come in from ppp0, get demasquareded,
> then have to either go a) to the LAN/eth0 or b)localhost bittorent
> process. You want to restrict b)

Well not just restrict - dynamically share per IP total incoming 
bandwidth with LAN traffic using HTB.


Andy.

  - is that correct? I have some
> suggestion, but need you to verify this part.
> 
> cheers,
> jamal
> 
> 

  reply	other threads:[~2004-04-17 21:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-15  9:42 IMQ / new Dummy device post Andy Furniss
2004-04-15 12:15 ` jamal
2004-04-15 19:35   ` Andy Furniss
2004-04-16  3:52     ` jamal
2004-04-16 19:35       ` Andy Furniss
     [not found]         ` <1082145341.1026.125.camel@jzny.localdomain>
2004-04-17 10:39           ` Andy Furniss
2004-04-17 12:09             ` jamal
2004-04-17 21:56               ` Andy Furniss [this message]
2004-04-18 14:28                 ` jamal
2004-04-18 16:35                   ` Andy Furniss
2004-04-18 20:34                     ` Andy Furniss
2004-04-18 21:07                       ` jamal
2004-04-18 21:31                         ` Andy Furniss
2004-04-18 21:45                           ` Andy Furniss
2004-04-18 20:53                     ` jamal
2004-04-18 21:23                       ` Martin Josefsson
2004-04-18 21:58                         ` Andy Furniss
2004-04-19  8:14                           ` Martin Josefsson
2004-04-19 12:33               ` syrius.ml
  -- strict thread matches above, loose matches on Subject: below --
2004-04-19 14:22 syrius.ml
2004-04-20  2:15 ` jamal
2004-04-21  1:43   ` syrius.ml
2004-04-21 12:49     ` syrius.ml
2004-04-21 20:19       ` syrius.ml
2004-04-22 13:16         ` jamal
2004-04-22 17:43           ` syrius.ml
2004-04-23 11:29             ` jamal

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=4081A824.5020107@dsl.pipex.com \
    --to=andy.furniss@dsl.pipex.com \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    /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.