QoS on incoming data

QoS on incoming data

[DervishD]

    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

Re: QoS on incoming data

[Christopher E. Brown]

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.

Re: QoS on incoming data

[Anders Eriksson]

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 majordomo@vger.kernel.org More majordomo info
  DervishD> at http://vger.kernel.org/majordomo- info.html Please read
  DervishD> the FAQ at http://www.tux.org/lkml/

Re: QoS on incoming data

[DervishD]

    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