From 12dcb6dd306bed6fde42cbec2d4c115b4faeecf4 Mon Sep 17 00:00:00 2001 From: teastep Date: Sun, 27 Nov 2005 01:22:26 +0000 Subject: [PATCH] Resolve conflict -- take 2 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3080 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/traffic_shaping.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Shorewall-docs2/traffic_shaping.xml b/Shorewall-docs2/traffic_shaping.xml index 645e6e5be..aec79d8e2 100644 --- a/Shorewall-docs2/traffic_shaping.xml +++ b/Shorewall-docs2/traffic_shaping.xml @@ -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). + 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). 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 - + \ No newline at end of file