Correct typo

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3113 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-12-02 22:56:59 +00:00
parent 77cadb064b
commit f0c28326a8

View File

@ -21,7 +21,7 @@
</author>
</authorgroup>
<pubdate>2005-11-26</pubdate>
<pubdate>2005-12-02</pubdate>
<copyright>
<year>2001-2004</year>
@ -110,12 +110,12 @@
end of that connection. This is mostly useful if you don't have access to
traffic control on the other side and if this other side has a faster
network connection than you do (the line speed between the systems is the
bottleneck, e.g. a DSL or Cable Modem connection to you provider's router,
the router itself is normally connected to a much faster backbone). So, if
you drop packets that are coming in too fast, the underlying protocol
might recognize this and slow down the connection. TCP has a builtin
mechanism for this, UDP has not (but the protocol over UDP might recognize
it , if there is any).</para>
bottleneck, e.g. a DSL or Cable Modem connection to your provider's
router, the router itself is normally connected to a much faster
backbone). So, if you drop packets that are coming in too fast, the
underlying protocol might recognize this and slow down the connection. TCP
has a builtin mechanism for this, UDP has not (but the protocol over UDP
might recognize it , if there is any).</para>
<para>The reason why queing is bad in these cases is, that you might have
packets which need to be priorized over others, e.g. VoIP or ssh. For this
@ -714,4 +714,4 @@ ppp0 4 90kbit 200kbit 3 default</pro
</orderedlist>
</section>
</section>
</article>
</article>