diff --git a/Shorewall/Perl/Shorewall/Tc.pm b/Shorewall/Perl/Shorewall/Tc.pm index edd0194b3..c40024119 100644 --- a/Shorewall/Perl/Shorewall/Tc.pm +++ b/Shorewall/Perl/Shorewall/Tc.pm @@ -664,6 +664,7 @@ sub validate_tc_class( ) { # my $parentref = $tcref->{$parentclass}; fatal_error "Unknown Parent class ($parentclass)" unless $parentref && $parentref->{occurs} == 1; + fatal_error "The parent class ($parentclass) specifies UMAX and/or DMAX; it cannot serve as a parent" if $parentref->{dmax}; $parentref->{leaf} = 0; } @@ -677,7 +678,7 @@ sub validate_tc_class( ) { $rate = convert_rate ( $full, $trate, 'RATE' ); $dmax = convert_delay( $dmax ); $umax = convert_size( $umax ); - fatal_error "A umax or dmax value must be specified for an hfsc class" unless $umax || $dmax; + fatal_error "DMAX must be specified when UMAX is specified" if $umax && ! $dmax; } else { $rate = convert_rate ( $full, $rate, 'RATE' ); } @@ -1008,7 +1009,7 @@ sub setup_traffic_shaping() { emit ( "run_tc qdisc add dev $device root handle $devnum: htb default $defmark r2q $r2q" , "run_tc class add dev $device parent $devnum: classid $devnum:1 htb rate $devref->{out_bandwidth} \$${dev}_mtu1" ); } else { - emit ( "run_tc qdisc add dev $device root handle $devnum: hfsc default $defmar r2q $r2qk" , + emit ( "run_tc qdisc add dev $device root handle $devnum: hfsc default $defmark" , "run_tc class add dev $device parent $devnum: classid $devnum:1 hfsc sc rate $devref->{out_bandwidth} ul rate $devref->{out_bandwidth}" ); } @@ -1097,29 +1098,15 @@ sub setup_traffic_shaping() { if ( $devref->{qdisc} eq 'htb' ) { emit ( "run_tc class add dev $device parent $devref->{number}:$parent classid $classid htb rate $rate ceil $tcref->{ceiling}kbit prio $tcref->{priority} \$${dev}_mtu1 quantum \$quantum" ); } else { - my $umax = $tcref->{umax}; my $dmax = $tcref->{dmax}; - unless ( $dmax ) { - # - # We must calculate the dmax but we know that umax has been specified - # - my $packetbits = 8 * $umax; - my $rateinbits = 1000 * $tcref->{rate}; - my $fullinbytes = $devref->{out_bandwidth}; - $fullinbytes =~ s/kbit//; - my $fullinbits = 1000 * $fullinbytes; - my $packetspersecond = $rateinbits / $packetbits; - my $totaldelayinms = 1000 * ( 1 - ( $rateinbits / $fullinbits ) ); - # - # In this calculation, '3' is a magic number. We can adjust it as necessary as we learn about this QDISC - # - $dmax = int( 3 * $totaldelayinms / $packetspersecond ); + if ( $dmax ) { + my $umax = $tcref->{umax} ? "$tcref->{umax}b" : "\${${dev}_mtu}b"; + emit ( "run_tc class add dev $device parent $devref->{number}:$parent classid $classid hfsc sc umax $umax dmax ${dmax}ms rate $rate ul rate $tcref->{ceiling}kbit" ); + } else { + warning_message "Leaf HFSC class $classid does not specify UMAX or DMAX" if $tcref->{leaf}; + emit ( "run_tc class add dev $device parent $devref->{number}:$parent classid $classid hfsc sc rate $rate ul rate $tcref->{ceiling}kbit" ); } - - $umax = $umax ? "${umax}b" : "\$${dev}_mtu"; - - emit ( "run_tc class add dev $device parent $devref->{number}:$parent classid $classid hfsc sc umax $umax dmax ${dmax}ms rate $rate ul rate $tcref->{ceiling}kbit" ); } emit( "run_tc qdisc add dev $device parent $classid handle ${classnum}: sfq quantum \$quantum limit 127 perturb 10" ) if $tcref->{leaf} && ! $tcref->{pfifo}; diff --git a/Shorewall/changelog.txt b/Shorewall/changelog.txt index ac7b8eb2a..33cf4941d 100644 --- a/Shorewall/changelog.txt +++ b/Shorewall/changelog.txt @@ -2,6 +2,8 @@ Changes in Shorewall 4.3.12 1) Eliminate 'large quantum' warnings. +2) Add HFSC support. + Changes in Shorewall 4.3.11 1) Reduce the number of arguments passed in may cases. diff --git a/Shorewall/configfiles/tcclasses b/Shorewall/configfiles/tcclasses index 44e63a103..034e73027 100644 --- a/Shorewall/configfiles/tcclasses +++ b/Shorewall/configfiles/tcclasses @@ -6,5 +6,6 @@ # See http://shorewall.net/traffic_shaping.htm for additional information. # ############################################################################### -#INTERFACE:CLASS MARK RATE CEIL PRIORITY OPTIONS +#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS +# DMAX:UMAX #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE diff --git a/Shorewall/releasenotes.txt b/Shorewall/releasenotes.txt index 968f4bd8b..0d0c8edd1 100644 --- a/Shorewall/releasenotes.txt +++ b/Shorewall/releasenotes.txt @@ -11,31 +11,40 @@ released late in 2009. has been combined with Shorewall-common to produce a single Shorewall package. -2) The Shorewall documentation and man pages have been purged of +2) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing + discipline has been added. HFSC is superior to the "Hierarchical + Token Bucket" queuing discipline where realtime traffic such as + VOIP is being used. + +3) Support for the "flow" traffic classifier has been added. This + classifier can help prevent multi-connection applications such as + BitTorrent from using an unfair amount of bandwidth. + +4) The Shorewall documentation and man pages have been purged of information about earlier Shorewall releases. The documentation describes only the behavior of Shorewall 4.3 and later versions. -3) The interfaces file OPTIONs have been extended to largely remove the +5) The interfaces file OPTIONs have been extended to largely remove the need for the hosts file. -4) It is now possible to define PREROUTING and OUTPUT marking rules +6) It is now possible to define PREROUTING and OUTPUT marking rules that cause new connections to use the same provider as an existing connection of the same kind. -5) Dynamic Zone support is once again available for IPv4; ipset support is +7) Dynamic Zone support is once again available for IPv4; ipset support is required in your kernel and in iptables. -6) A new AUTOMAKE option has been added to shorewall.conf and +8) A new AUTOMAKE option has been added to shorewall.conf and shorewall6.conf. Setting this option will allow Shorewall to skip the compilation phase during start/restart if no configuration changes have occurred since the last start/restart. -7) The LIMIT:BURST column in /etc/shorewall/policy +9) The LIMIT:BURST column in /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT column in /etc/shorewall/rules (/etc/shorewall6/rules) may now be used to limit on a per source IP or per destination IP basis. -8) Support for per-IP traffic shaping classes has been added. +10) Support for per-IP traffic shaping classes has been added. ---------------------------------------------------------------------------- M I G R A T I O N I S S U E S @@ -97,7 +106,49 @@ None. N E W F E A T U R E S I N 4 . 3 . 12 ---------------------------------------------------------------------------- -None. +1) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing + discipline has been added. HFSC is superior to the "Hierarchical + Token Bucket" queuing discipline where realtime traffic such as + VOIP is being used. + + An excellent overview of HFSC on Linux may be found at + http://linux-ip.net/articles/hfsc.en/. + + To use HFSC, several changes need to be made to your traffic + shaping configuration: + + - To use HFSC on an interface rather than HTB, specify the + 'hfsc' option in the OPTIONS column in the interfaces's + entry in /etc/shorewall/tcdevices. + + - Modify the RATE colum for each 'leaf' class (class with no + parent class specified) defined for the interface. + + When using HFSC, the RATE column may specify 1, 2 or 3 + pieces of information separated by colons (":"). + + 1. The Guaranteed bandwidth (as always). + 2. The Maximum delay (DMAX) that the first queued packet + in the class should experience. The delay is expressed + in milliseconds and may be followed by 'ms' (e.g., + 10ms. Note that there may be no white space between the + number and 'ms'). + 3. The maximum transmission unit (UMAX) for this class of + traffic. If not specified, the MTU of the interface is + used. The length is specified in bytes and may be + followed by 'b' (e.g., 800b. Note that there may be no + white space between the number and 'b'). + + DMAX should be specified for each leaf class. The Shorewall + compiler will issue a warning if DMAX is omitted. + + Example: + + full/2:10ms:1500b + + Guaranteed bandwidth is 1/2 of the devices + OUT-BANDWIDTH. Maximum delay is 10ms. Maximum packet + size is 1500 bytes. ---------------------------------------------------------------------------- N E W F E A T U R E S IN 4 . 3 diff --git a/docs/traffic_shaping.xml b/docs/traffic_shaping.xml index be0341a2a..a023568a8 100644 --- a/docs/traffic_shaping.xml +++ b/docs/traffic_shaping.xml @@ -64,15 +64,20 @@ - The LARTC HOWTO: The LARTC HOWTO: http://www.lartc.org - The HTB User's Guide: The HTB User's Guide: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm + + HFSC Scheduling with Linux: http://linux-ip.net/articles/hfsc.en/ + + Some of the documents listed at http://www.netfilter.org/documentation/index.html#documentation-howto. @@ -117,15 +122,17 @@ your bandwidth, this queuing algorithm will not stop it from doing so. - For Shorewall traffic shaping we use two algorithms, one is called - HTB (Hierarchical Token Bucket) and SFQ (Stochastic Fairness Queuing). SFQ - is easy to explain: it just tries to track your connections (tcp or udp - streams) and balances the traffic between them. This normally works well. - HTB allows you to define a set of classes, and you can put the traffic you - want into these classes. You can define minimum and maximum bandwidth - settings for those classes and order them hierarchically (the less - prioritized classes only get bandwidth if the more important have what - they need). Shorewall builtin traffic shaping allows you to define these + For Shorewall traffic shaping we use three algorithms: HTB + (Hierarchical Token Bucket), HFSC (Hierarchical Fair Service Curves) and + SFQ (Stochastic Fairness Queuing). SFQ is easy to explain: it just tries + to track your connections (tcp or udp streams) and balances the traffic + between them. This normally works well. HTB and HFSC allow you to define a + set of classes, and you can put the traffic you want into these classes. + You can define minimum and maximum bandwidth settings for those classes + and order them hierarchically (the less prioritized classes only get + bandwidth if the more important have what they need). Additionally, HFSC + allows you to specify the maximum queuing delay that a packet may + experience. Shorewall builtin traffic shaping allows you to define these classes (and their bandwidth limits), and it uses SFQ inside these classes to make sure, that different data streams are handled equally. If SFQ's default notion of a 'stream' doesn't work well for you, you can change it @@ -308,7 +315,9 @@ This file allows you to define the incoming and outgoing bandwidth for the devices you want traffic shaping to be enabled. That means, if you want to use traffic shaping for a device, you have to define it - here. + here. For additional information, see shorewall-tcdevices + (5). Columns in the file are as follows: @@ -378,6 +387,18 @@ will be associated with classes on this interface. + + + hfsc + + + Shorewall normally uses the Hierarchical + Token Bucket queuing discipline. When + is specified, the + Hierarchical Fair Service Curves + discipline is used instead. + + @@ -411,7 +432,9 @@ ppp0 6000kbit 500kbit /etc/shorewall/tcclasses This file allows you to define the actual classes that are used to - split the outgoing traffic. + split the outgoing traffic. For additional information, see shorewall-tcclasses + (5). @@ -453,6 +476,12 @@ ppp0 6000kbit 500kbit role="bold">If the sum of the RATEs for all classes assigned to an INTERFACE exceed that interfaces's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit will not be honored. + + When using HFSC, this column may contain 1, 2 or 3 pieces of + information separated by colons (":"). In addition to the minimum + bandwidth, leaf classes must specify DMAX (maximum delay in + milliseconds) and may optionally specify UMAX (the largest packet + expected in the class). @@ -1315,6 +1344,31 @@ ppp0 4 90kbit 200kbit 3 default +
+ An HFSC Example + + As mentioned at the top of this article, there is an excellent + introduction to HFSC at http://linux-ip.net/articles/hfsc.en/. + At the end of that article are 'tc' commands that implement the + configuration in the article. Those tc commands correspond to the + following Shorewall traffic shaping configuration. + + /etc/shorewall/tcdevices: + + #INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS +eth0 - 1000kbit hfsc + + /etc/shorewall/tcclasses: + + #INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS +# DMAX:UMAX +1:10 1 500kbit full 1 +1:20 2 500kbit full 1 +1:10:11 3 400kbit:53ms:1500b full 2 +1:10:12 4 100kbit:30ms:1500b full 2 +
+
Shaping Download Traffic diff --git a/manpages/shorewall-tcclasses.xml b/manpages/shorewall-tcclasses.xml index 588fd186b..284f6726f 100644 --- a/manpages/shorewall-tcclasses.xml +++ b/manpages/shorewall-tcclasses.xml @@ -170,7 +170,7 @@ RATE - - rate + rate[:dmax[:umax]] The minimum bandwidth this class should get, when the traffic @@ -179,6 +179,19 @@ honored. Similarly, if the sum of the rates of sub-classes of a class exceed the CEIL of the parent class, things don't work well. + + When using the HFSC queuing discipline, leaf classes should + specify dmax, the maximum delay in + milliseconds that the first queued packet for this class should + experience. May be expressed as an integer, optionally followed by + 'ms' with no intervening white space (e.g., 10ms). + + HFSC leaf classes may also specify + umax, the largest packet expected in this + class. May be expressed as an integer. The unit of measure is + bytes and the integer may be optionally + followed by 'b' with no intervening white space (e.g., 800b). + @@ -388,7 +401,7 @@ Those that begin with "nfct-" are Netfilter connection tracking fields. As shown above, we recommend flow=nfct-src; that means that we want to use the source IP address - before NAT as the key. + before NAT as the key. diff --git a/manpages/shorewall-tcdevices.xml b/manpages/shorewall-tcdevices.xml index 219391b90..aead56559 100644 --- a/manpages/shorewall-tcdevices.xml +++ b/manpages/shorewall-tcdevices.xml @@ -156,13 +156,18 @@ OPTIONS - {-|classify} + role="bold">{classify|hfsc} ,...} - classify ― When specified, Shorewall will not generate tc or - Netfilter rules to classify traffic based on packet marks. You must - do all classification using CLASSIFY rules in ― When specified, Shorewall will not + generate tc or Netfilter rules to classify traffic based on packet + marks. You must do all classification using CLASSIFY rules in shorewall-tcrules(5). + + - Shorewall normally uses the + Hierarchical Token Bucket queuing discipline. + When is specified, the Hierarchical + Fair Service Curves discipline is used instead. diff --git a/manpages6/shorewall6-tcclasses.xml b/manpages6/shorewall6-tcclasses.xml index bbcd828eb..f54f7d5b3 100644 --- a/manpages6/shorewall6-tcclasses.xml +++ b/manpages6/shorewall6-tcclasses.xml @@ -166,13 +166,27 @@ RATE - - rate + rate[:dmax[:umax]] The minimum bandwidth this class should get, when the traffic load rises. If the sum of the rates in this column exceeds the INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be - honored. + honored. Similarly, if the sum of the rates of sub-classes of a + class exceed the CEIL of the parent class, things don't work + well. + + When using the HFSC queuing discipline, leaf classes should + specify dmax, the maximum delay in + milliseconds that the first queued packet for this class should + experience. May be expressed as an integer, optionally followed by + 'ms' with no intervening white space (e.g., 10ms). + + HFSC leaf classes may also specify + umax, the largest packet expected in this + class. May be expressed as an integer. The unit of measure is + bytes and the integer may be optionally + followed by 'b' with no intervening white space (e.g., 800b). diff --git a/manpages6/shorewall6-tcdevices.xml b/manpages6/shorewall6-tcdevices.xml index f457c65a3..99c369329 100644 --- a/manpages6/shorewall6-tcdevices.xml +++ b/manpages6/shorewall6-tcdevices.xml @@ -156,13 +156,18 @@ OPTIONS - {-|classify} + role="bold">{classify|hfsc} ,...} - classify ― When specified, Shorewall6 will not generate tc or - Netfilter rules to classify traffic based on packet marks. You must - do all classification using CLASSIFY rules in shorewall6-tcrules(5). + ― When specified, Shorewall will not + generate tc or Netfilter rules to classify traffic based on packet + marks. You must do all classification using CLASSIFY rules in shorewall-tcrules(5). + + - Shorewall normally uses the + Hierarchical Token Bucket queuing discipline. + When is specified, the Hierarchical + Fair Service Curves discipline is used instead.