extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-24 15:18:53 +01:00
Code Issues Packages Projects Releases Wiki Activity

Resolve conflict -- take 2

Browse Source 
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
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Shorewall-docs2/traffic_shaping.xml
View File

@ -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 connection to you providers router, the router
itself is normally connected to a much faster backbone). So, if you drop
packets that are coming in too fast, the underlaying 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 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 underlaying 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>