extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2025-01-13 09:08:12 +01:00
Code Issues Packages Projects Releases Wiki Activity

Clarify dropping of inbound traffic via traffic shaping

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3045 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-11-21 16:41:15 +00:00
parent a55757d065
commit 653212c073
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Shorewall-docs2/traffic_shaping.xml
View File

@ -21,7 +21,7 @@
</author>
</authorgroup>
<pubdate>2005-10-15</pubdate>
<pubdate>2005-11-21</pubdate>
<copyright>
<year>2001-2004</year>
@ -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 <emphasis>does</emphasis> 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
<filename>/etc/shorewall/tcdevices</filename> 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</pro
</orderedlist>
</section>
</section>
</article>
</article>