From 653212c07378d8de9a06267752d83526a2db22b9 Mon Sep 17 00:00:00 2001 From: teastep Date: Mon, 21 Nov 2005 16:41:15 +0000 Subject: [PATCH] Clarify dropping of inbound traffic via traffic shaping git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3045 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/traffic_shaping.xml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Shorewall-docs2/traffic_shaping.xml b/Shorewall-docs2/traffic_shaping.xml index aa4dbca41..b7ad2017b 100644 --- a/Shorewall-docs2/traffic_shaping.xml +++ b/Shorewall-docs2/traffic_shaping.xml @@ -21,7 +21,7 @@ - 2005-10-15 + 2005-11-21 2001-2004 @@ -99,7 +99,12 @@ the packets were already received by your network card before you can decide what to do with them. So the only choice would be to drop them which normally makes no sense (since you received the packet already, it - went through the possible bottleneck (the incoming connection). The next + went through the possible bottleneck (the incoming connection); dropping + packets does have an advantage when you are connected + to the internet using a Cable Modem or DSL because it can prevent large + queues of download traffic from forming at your ISP and thus can improve + response time (see the definition of the IN-BANDWIDTH column of the + /etc/shorewall/tcdevices file below). The next possible bottleneck might come if the packet leaves on another interface, so this will be the place where queuing might occur. So, defining queues for incoming packages is not very useful, you just want to have it @@ -714,4 +719,4 @@ ppp0 4 90kbit 200kbit 3 default - + \ No newline at end of file