Resolve conflict -- take 2

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3080 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-11-27 01:22:26 +00:00
parent d7365302a5
commit 12dcb6dd30

View File

@ -110,12 +110,12 @@
end of that connection. This is mostly useful if you don't have access to 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 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 network connection than you do (the line speed between the systems is the
bottleneck, e.g. a DSL connection to you providers router, the router bottleneck, e.g. a DSL or Cable Modem connection to you provider's router,
itself is normally connected to a much faster backbone). So, if you drop the router itself is normally connected to a much faster backbone). So, if
packets that are coming in too fast, the underlaying protocol might you drop packets that are coming in too fast, the underlaying protocol
recognize this and slow down the connection. TCP has a builtin mechanism might recognize this and slow down the connection. TCP has a builtin
for this, UDP has not (but the protocol over UDP might recognize it , if mechanism for this, UDP has not (but the protocol over UDP might recognize
there is any).</para> it , if there is any).</para>
<para>The reason why queing is bad in these cases is, that you might have <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 packets which need to be priorized over others, e.g. VoIP or ssh. For this