FreeBSD Traffic Shaping?

[Vincent Poy]

On 6 Feb 2004, Dan Pelleg wrote:

> Vincent Poy <vince at oahu.WURLDLINK.NET> writes:
>
> > On 6 Feb 2004, Dan Pelleg wrote:
> >
> > > Vincent Poy <vince at oahu.WURLDLINK.NET> writes:
> > >
> > > > Greetings all:
> > > >
> > > > 	I have a ADSL connection where the upstream pipe is smaller than
> > > > the downstream with it at 1.5Mbps/384kbps now and will be upgrading to
> > > > 6Mbps/608kbps soon.  The issue I'm having is that whenever I upload, it
> > > > fills the upstream to full capacity and the downstream would lag as the
> > > > ACKs can't be send back in time.  I was told that with traffic shaping or
> > > > fair queue routing would solve this issue but I only have one NIC
> > > > interface as I am running FreeBSD on a fully loaded notebook with a
> > > > Pentium 4M-2.6Ghz CPU, 2GB RAM and 60GB 7200RPM HDD with a 10/100 3COM xl0
> > > > built in NIC.  The problem is that I have 8 static IP's with my ISP so
> > > > that the LAN IP's, x.x.x.224-.231 netmask 255.255.255.0 are all locally on
> > > > the LAN so I want those to use the full speed of the connection without
> > > > traffic shaping.  The NIC also has the 192.168.x.x netmask 255.255.0.0
> > > > addresses for the local LAN as well so how do I setup traffic shaping in
> > > > this scenario so that only traffic that actually uses x.x.x.1 from the
> > > > x.x.x.224 IP that isn't local LAN traffic actually use traffic shaping or
> > > > fair queue routing while LAN traffic will just use the full speed.  I
> > > > already have these options in the KERNEL config.
> > > >
> > > > options         IPFIREWALL
> > > > options         IPDIVERT
> > > > options         DUMMYNET
> > > > options         BRIDGE
> > > >
> > > > 	Thanks for your help in advance!
> > >
> > > See ipfw(8). You can match rules by interface or address mask, so you don't
> > > need to touch LAN traffic.
> >
> > 	That's the part I'm confused about.  Since I only have one
> > interface, I assume I have to do it by address mask but how would one
> > define it as for example,
> >
> > 10.0.0.224-231 would not use the traffic shaper but 10.0.0.1-223 as well
> > as 10.0.0.232-254 would?
> >
>
> Whatever rule you have for shaping, you condition it on "from
> 10.0.0.224/28" (or whatever the appropriate mask is). Or use the negation
> of the condition and have a special case for non-capped traffic (so
> internet traffic falls through to the next rule).

	That's the part where it becomes difficult since even though I
have 8 IP's, it's still on a /24 mask so only the 8 IP's in that /24 are
actually local.

> > > Correct, the problem when you upload on an assymetric link has to do with
> > > acknowledgment packets that downloading apps need to send back to the
> > > remote server, and they have to wait in the upload queue (which is
> > > saturated). You need to prioritize those. One way to do this is to filter
> > > on small iplen. This has been discussed in the mailing lists in the past
> > > (try the archive of the ipfw@ list). Just remember you can only shape
> > > outbound packets (ie, leaving your computer). Doesn't matter if they're up
> > > or down the DSL line, just that they go out (shaping incoming traffic makes
> > > no sense).
> >
> > 	True.  But when you have the shaping, do you actually set it to
> > the speed of the line or do you set it to like 5% below the speed of the
> > line and on the acknowledgement packets, does traffic shaping actually
> > reserve some space for that to go back or does it just queue it a certain
> > way?  Thanks.
>
> You need to handle the ack packets specially in your rules, it will not
> reserve bandwidth for them unless you tell it to.
>
> With ipfw, there are two ways to do this. Again I'm only talking about
> packets leaving your computer and heading to the internet (so condition the
> rules appropriately)
>
> 1. two pipes, one with static allocation (say 95% of bw, or whatever works
> for you), other can have unlimited bw. Non-ack packets go to the capped
> pipe, ack packets go to the other one.
>
> alternatively,
>
> 2. one pipe (unlimited bw), two queues in that pipe, one queue has a much
> much higher weight. Non-ack packets go to one pipe (low weight), ack
> packets to the other. This approach actually lets you use the entire
> available bandwidth for either kind of traffic if there is no other demand
> for it. It also frees you from having to specify the maximum bandwidth,
> which can change when you, say, upgrade your DSL, or even take the laptop
> to a wifi cafe.

	The second approach does seem to work better since basically, it
prioritizes the ack portion.  I guess ipfw is something I have to figure
out. :)


Cheers,
Vince - vince at WURLDLINK.NET - Vice President             ________   __ ____
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / |  / |[__  ]
WurldLink Corporation                                  / / / /  | /  | __] ]
San Francisco - Honolulu - Hong Kong                  / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____]
Almighty1 at IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin