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
On Tue, 11 Jun 2002, DervishD wrote:
> 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.
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
>>>>> On Tue, 11 Jun 2002, "DervishD" == DervishD wrote:
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 :)
>You said way back that it was only wget that did hog the andbith,
>right?
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