[nSLUG] upstream bandwidth with iptables

Dop Ganger nslug at fop.ns.ca
Tue Jun 3 21:18:03 ADT 2003

On Tue, 3 Jun 2003, Ben Armstrong wrote:

> On Tue, Jun 03, 2003 at 03:36:32PM -0300, Dop Ganger wrote:
> > Ummmm... No. Using whitespace like that is bad, mmmkay?
> Heh.  Perl has its warts too.  But really, this is a dead-end topic, so I
> will hold my tongue. :)

Well, I was toying with this a bit further, and I think a perl script that
reads a conf file to generate its output, which is in turn a bash script
that can be run from /etc/init.d would be a neat way to do it. That way,
the front end could be anything - one example that occurred to me was a
public generator on the web that anyone can use to generate a custom
rc.qos script, which also archives the input and can be used as a
reference library. One could also write a user interface in python, if one
wanted to badly enough ;->

> > > OK, so long as debconf isn't providing functionality not already in the app,
> > > this is fine.
> >
> > Shirley "so long as debconf isn't providing functionality already in the
> > app"?
> Well yes, it goes goes without saying that debconf does, in fact, provide
> some functionality not already in the app.

OK, fair enough :-)


> In other words, ideally the
> application allows a user to configure it with the same ease that debconf
> does, and the only thing debconf really does is provide a consistent user
> interface at initial install time for setting up a sane default
> configuration.
> Is that clearer?

Well, what I was thinking was more along the lines of "debianising" it
(for lack of a better term); having a user interface that can take debconf
input and create the QoS rules from there, meaning it'd fit in better with
the rest of the Debian packages (as opposed to running a separate
interface). One piece of software I've seen that does this very well is
Jay's Iptables Firewall (http://firewall-jay.sourceforge.net/) - a really
nicely done dialog interface.

> > De-TLAing:
> > > > I think so, yes, for TCP at least. The problem is, the sfq queue is
> >
> > TCP is just TCP/IP.
> You missed sfq.  TCP I knew. :)

Oops... That might be handy :-)

sfq is Stochastic Fair Queueing, it's basically a bunch of queues, one per
TCP or UDP session, and it iterates over each queue in turn to dequeue the
traffic out interface. It has no effect while traffic isn't maxing out the
queue, but when you've got one stream maxing out the bandwidth
allocated to the queue that's choking all the others it's pretty helpful.
The problem is when you have a lot of streams wanting to send a lot of
data, and the buffers build up (this is the problem I was alluding to
earlier); packets get dropped, which means that the traffic after it may
well be useless as it will be resent anyway, but said packets are already
in the queue using up valuable bandwidth. What I'd like to do is figure
out some way to send a quench message back up the stack to do some flow
control, so not so much data is being sent through. I suspect tbf may be
the answer for this.

> > lartc = http://www.lartc.org/lartc.html
> My homework this week is to read and understand this completely.

Mmmm. The letters "G", "F" and "L" come to mind ;->

> > > > UDP is another matter entirely, but I don't have any applications that
> > > > throw out data quick enough that I can make any meaningful measurements.
> > >
> > > How about file transfers over a cipe tunnel (or pick your favourite
> > > VPN-over-UDP)?
> >
> > All the traffic going out the external interface will be seen as UDP
> > traffic on port (whateverportcipeuses). If you want to do QoS on traffic
> > going out over the VPN, you'll need to attach a qdisc and filter to the
> > VPN virtual interface.
> Hm.  Actually, I meant you might get meaningful measurements if you filter
> on the encapsulating interface and blast across some files down the cipe
> tunnel.  This is an academic exercise only since, as you said, filtering on
> the VPN interface makes more sense.

Reading back, I think I may have been ambiguous; for "you'll need to
attach a qdisc and filter to the VPN virtual interface", I mean you will
need to attach both a qdisc and a filter to the VPN virtual interface
(cipe0?). It'll be useful if you're doing any interactive traffic and you
have some bulk traffic on the line too.

> How about XPilot?  The packet sizes vary quite a bit, but average around
> 200-300 bytes per frame, iirc, and a "typical" framerate is 12 FPS, although
> much higher framerates are possible.  Running a smooth XPilot server on a
> network carrying large amounts of other kinds of traffic is quite
> problematic.  I'm sure those who host XPilot servers on networks where they
> control their own routing and who are having problems with smooth gameplay
> would be interested.

Well, assuming a "would be nice" framerate of 25 FPS, and 300 bytes per
frame, I make 7500 bytes per second; adding 15345 (the xpilot port,
according to my /etc/services) to the LOBHIPT and LOBHIPU strings should
do the trick quite nicely.

> > > I have been meaning to dabble with alioth anyway, so I might as well.  Any
> > > idea what to call the project?  My mind is drawing a complete blank.
> >
> > I'm sure there's a pun on "que sera sera" just waiting to burst out into
> > existence... :-)
> I'm sure there is. :)  Still waiting, too ...

Hmmm... How about QSS, short for "Meaningless TLA Acronym"?

Cheers... Dop.

More information about the nSLUG mailing list