On 14-05-30 05:07 PM, sven falempin wrote:
Just curious. Because TCP got flow and congestion control it should be
possible to reduce the input bandwith of tcp connection even without
controlling the previous hop ???
Yes, but consider a router with 3 interfaces: WAN, LAN1 and LAN2. Let us
assume WAN is a 100Mbps circuit, LAN1 is a gigabit ethernet connection,
and LAN2 is only 10Mbps - perhaps it's an 802.11B WiFi card in AP mode,
or perhaps it's a circuit to a branch office; it doesn't matter except
that it's noticeably slower.
I will ignore NAT for simplicity; AFAIK all the concepts remain valid
regardless.
Now, say you want to reserve some portion of bandwidth for SSH (tcp port
22, to make things easy). Perhaps you've decided you want to allow up
to 80Mbps for SSH traffic on the WAN. (This is a bad policy, and I'll
now explain why.)
We can easily control packets outbound to WAN; this is the common use case.
Let's say we did the same thing to packets arriving on the WAN
interface, and that's where we cap SSH at 80Mbps.
Note that this does not prevent the entire 100Mbps pipe filling up with
SSH packets - although, as you point out, since that is a TCP protocol,
dropping 20% of the packets will fairly quickly cause that TCP session
to stop saturating the link... but it can still happen briefly.
What's worse, though, is that that although the WAN is slower than LAN1,
implying that we can (generally) always egress packets to LAN1 as they
arrive on the WAN, what do we do with LAN2? Force-feed 80Mbps onto an
10Mbps media somehow? That's impossible. What happens there is even
without any policing (rate-limiting), we'll be dropping packets. Or at
least we will if we're pushing more than 10Mbps...
If we instead said the policy was "80% of the connection may be used for
SSH traffic", we would apply rules that apply to packets outbound to
each interface, and each rule would limit traffic to 80% of that
interface's bandwidth. The actual traffic flows seen by the client now
match our (more flexible) policy.
It is true that in a perfectly symmetric situation, assuming 100%
utilization, it doesn't matter where you drop packets or where you
rate-limit flows; nearly the same effect will occur no matter what.
My point, which I realize I've now addressed from three different angles
without a unifying overview, is that there's no point in limiting on
ingress: the packets are already there whether you choose to forward
them or not.
In the case of TCP, dropping packets on ingress will work, but is like
using a sledgehammer to kill a fly - there are much more subtle ways to
do it that don't break everything nearby.
In the case of UDP, dropping packets may be completely pointless,
depending on the protocol, or it might have a similar effect as TCP.
In either case, applying classification on ingress *for every interface*
and policing on egress *for every interface* will (generally) give you
the flexibility you need without painting yourself into a corner.
I'm trying to figure out how to formulate my old garden-hose analogy,
but apparently I've forgotten how to make it sound meaningful - stay tuned.
--
-Adam Thompson
athom...@athompso.net
