From acc985a2904403b5daeab0fb11399887bcda79b9 Mon Sep 17 00:00:00 2001 From: Tom Eastep Date: Sat, 5 Dec 2009 08:07:34 -0800 Subject: [PATCH] Update 'flow=' description in the TC doc --- docs/traffic_shaping.xml | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/docs/traffic_shaping.xml b/docs/traffic_shaping.xml index 35ec1cbc5..ba25cf69c 100644 --- a/docs/traffic_shaping.xml +++ b/docs/traffic_shaping.xml @@ -606,25 +606,26 @@ ppp0 6000kbit 500kbit flow=keys - Shorewall attaches an SFQ - queuing discipline to each leaf HTB class. SFQ ensures that each - flow gets equal access to the interface. - The default definition of a flow corresponds roughly to a - Netfilter connection. So if one internal system is running + queuing discipline to each leaf HTB and HFSC class. SFQ ensures + that each flow gets equal access to the + interface. The default definition of a flow corresponds roughly + to a Netfilter connection. So if one internal system is running BitTorrent, for example, it can have lots of 'flows' and can thus take up a larger share of the bandwidth than a system having only a single active connection. The classifier (module cls_flow) works around this by letting you define what a 'flow' is. The clasifier must be used carefully or it can block off all traffic on an - interface! The flow option can be specified for an HTB leaf - class (one that has no sub-classes). We recommend that you use - the following: + interface! The flow option can be specified for an HTB or HFSC + leaf class (one that has no sub-classes). We recommend that you + use the following: - Shaping internet-bound traffic: flow=nfct-src + Shaping internet-bound traffic: flow=nfct-src - Shaping traffic bound for your local net: - flow=dst + Shaping traffic bound for your local net: flow=dst These will cause a 'flow' to consists of the traffic