QoS on incoming data

Hi all :)

After reading a bit of the HOWTO about traffic control and
advanced routing, I have a doubt about the queue disciplines and traffic shaping.

I've seen that, except the 'ingress' qdisc (and maybe the
hierarchycal token bucket) all other qdisc's seem to be only valid for outgoing traffic, although I suppose that some of those qdisc could be easily applied to incoming traffic.

But the key point is that: I think that the better way of
controlling the incoming bandwidth is the Token Bucket Filter, just as the autor of the HOWTO says, but I think (may be wrong here) that the TBF is only valid for outgoing traffic. Moreover, if, just as the HOWTO says, we set up the TBF for controlling the incoming traffic at, lets say, 250kb/s for an ADSL access of 256kb/s, it won't control the outgoing traffic, since the bandwidth of that traffic is just 128kb/s. That is: TBF is not valid if applied to both incoming and outgoing traffic, and anyway I think that only controls the outgoing part.

Please excuse the continous questions about this subject, but I'm
new to this and wanting to understand a bit this powerful feature.

Thanks in advance :)
Raúl

The ingress system is for corner cases and special situations. In general you do not control the flows *entering* the router, but *leaving* it.

I router or system *cannot* limit the traffic it receives, if it is coming down the wire at you you receive it. The ingress system simply lets you decide to discard or delay a packet before it gets passed to the local stack.

This allows you to cover a few corner cases, such as not being in control of the upstream router where you *must* limit traffic *to* the local machine.

For an example 2 interface machine, you receive traffic on A and limit its retransmission on B, you receive traffic on B and limit its retransmission on A.

For the special case of a server that needs to limit traffic to/from itself you use an ingress rule to throttle incoming traffic, and an egress rule to throttle outbound. To control *any* bi-directional flow requires at least 2 rules.

--
I route, therefore you are.

You said way back that it was only wget that did hog the andbith, right? Assuming that you speak to the same servers all the time (i.e. for both the wget and non-wget cases), how about playing with the tcp windows? If the send and receive machines are the same, any difference have to come from different tcp setups. Check what options, if any wget and others are setting. I bet announcing a large receive window can folld your upstream network (your ISP's queues) and make the rest of the tcp timer magics run on longer control loops, this making it respond to changes more sluggishly.

/Anders

DervishD> Hi all :)

DervishD> After reading a bit of the HOWTO about traffic control DervishD> and advanced routing, I have a doubt about the queue DervishD> disciplines and traffic shaping.

DervishD> I've seen that, except the 'ingress' qdisc (and maybe the DervishD> hierarchycal token bucket) all other qdisc's seem to be DervishD> only valid for outgoing traffic, although I suppose that DervishD> some of those qdisc could be easily applied to incoming DervishD> traffic.

DervishD> But the key point is that: I think that the better way of DervishD> controlling the incoming bandwidth is the Token Bucket DervishD> Filter, just as the autor of the HOWTO says, but I think DervishD> (may be wrong here) that the TBF is only valid for DervishD> outgoing traffic. Moreover, if, just as the HOWTO says, DervishD> we set up the TBF for controlling the incoming traffic DervishD> at, lets say, 250kb/s for an ADSL access of 256kb/s, it DervishD> won't control the outgoing traffic, since the bandwidth of DervishD> that traffic is just 128kb/s. That is: TBF is not valid if DervishD> applied to both incoming and outgoing traffic, and anyway DervishD> I think that only controls the outgoing part.

DervishD> Please excuse the continous questions about this subject, DervishD> but I'm new to this and wanting to understand a bit this DervishD> powerful feature.

DervishD> Thanks in advance :) Raúl - To unsubscribe from this list:
DervishD> send the line "unsubscribe linux-kernel" in the body of a DervishD> message to [email protected] More majordomo info DervishD> at http://vger.kernel.org/majordomo- info.html Please read DervishD> the FAQ at http://www.tux.org/lkml/

Hi Anders :)

Well, not exactly. Let's say that wget seems more 'aggresive',
but really the one who gets all the speed is the *first* downloading program started, although some of them seems to be more friendly than others. Wget is a corner case. Lukemftp is less aggresive.

I've already considered the tcp windows issue, but is not the
case (IMHO). I think that's more probable the option regarding ISP large queues.

Thanks for your answer and interest :))
Raúl