From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>
To: lartc@vger.kernel.org
Subject: [LARTC] New HTB-derived qdisc for accounting?
Date: Sat, 04 Jun 2005 12:45:30 +0000 [thread overview]
Message-ID: <42A1A26A.1010700@gmx.net> (raw)
Hi,
at my local university network, I have to make sure no student
uploads more than x GB/day. So far, I give them unlimited bandwidth
until they have more than y GB (y<x) upload. After that, I use the
u32 filter to associate the affected IP address with a HTB class
limited to the rate (remainingtraffic/remainingtime).
Since the accounting is done with ipt_ACCOUNT right now and the
netfilter framework obviously can't know whether a packet was
dropped because the queue was full, dropped packets are counted as
traffic, but that is somewhat unfair.
Can I do the accounting with the traffic control framework in the
kernel instead of using ipt_ACCOUNT? Giving every IP its own htb
class and setting that to an incredibly high limit to do the
accounting seems overkill (there is no point in forcing HTB to
do all the calculations for shaping if I only want to count)
especially because I'd have to do that for a sparsely populated
/16 network (about 1500-2800 hosts).
One (not that sophisticted) idea is to leave the accounting "as is"
and add a "dropped bytes" count to htb. This could be subtracted
from the numbers ipt_ACCOUNT gives me. That would modify the output
of "tc class ls" from
Sent 86136037 bytes 103963 pkt (dropped 283998, overlimits 0 requeues 0)
to
Sent 86136037 bytes 103963 pkt (dropped 385953282 bytes 283998 pkt, overlimits 0 requeues 0)
Proposal:
----------------------------------
Another idea would be to create a qdisc HTBQ (HTB with quota)
derived from HTB with the following characteristics:
htb_rate=min(htbq_rate, (alreadysent=>htbq_squota)?((htbq_quota-alreadysent)/remtime):htbq_rate)
htb_ceil=htbq_ceil //this is just passed on
htb_burst=htbq_burst
htb_cburst=htbq_cburst
htb_prio=htbq_prio
htb_quantum=htbq_quantum //should be set automatically
htbq_interval seconds //time after which quota is reset
htbq_starttime seconds //time when the first interval starts
htbq_quota bytes //maximum allowed bytes
htbq_squota bytes //unshaped quota
htbq_rate is optional, unlimited if not set
htbq_ceil is optional
htbq_burst is optional
htbq_cburst is optional
htbq_prio is mandantory
htbq_quantum is optional
htbq_interval is mandantory
htbq_starttime is optional, defaults to unixtime 0
htbq_quota is mandantory
htbq_squota is optional, defaults to 0 (shape from beginning)
Basic description:
Case 1: already sent bytes are less than htbq_squota
if htbq_{rate,ceil,burst,cburst,quantum} is set then
do normal htb shaping with copied parameters
else
pass on packets directly to network device
Case 2: already sent bytes are greater or equal than htbq_squota
if htbq_{rate,ceil,burst,cburst,quantum} is set then
do htb shaping with copied parameters except
htb_rate=min(htbq_rate, (htbq_quota-alreadysent)/remtime)
htb_ceil=min(htbq_ceil, (htbq_quota-alreadysent)/remtime)
else
do htb shaping with following parameters
htb_rate=(htbq_quota-alreadysent)/remtime
htb_ceil=(htbq_quota-alreadysent)/remtime
This would surely be helpful for some admins who have to limit
users to a certain quota without constantly shaping their
network traffic or pulling the plug once the quota is full.
Thoughts?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next reply other threads:[~2005-06-04 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-04 12:45 Carl-Daniel Hailfinger [this message]
2005-06-04 12:54 ` [LARTC] New HTB-derived qdisc for accounting? Peter Surda
2005-06-04 13:21 ` Carl-Daniel Hailfinger
2005-06-04 13:35 ` Patrick McHardy
2005-06-04 13:39 ` Peter Surda
2005-06-04 18:46 ` Carl-Daniel Hailfinger
2005-06-06 14:02 ` Patrick McHardy
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=42A1A26A.1010700@gmx.net \
--to=c-d.hailfinger.devel.2005@gmx.net \
--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 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.