On Wed, Mar 12, 2008 at 11:50 AM, Bruno Wolff III <bruno@xxxxxxxx> wrote:
In case of dynamic throttling we won't be having any _fixed_ rate at which the connections assigned for updates will be able receive the packets. It means packets would be dropped frequently to implement policing. Isn't this waste of resources?On Wed, Mar 12, 2008 at 01:59:46 -0700,You would still need to write the rules that do the shaping. However some
Andrew Farris <lordmorgul@xxxxxxxxx> wrote:
>
> I was thinking more along the lines of just the local machine's behavior
> with different connections having higher or lower priority for outbound
> (which is often what hurts response time the most for slower connections
> while longer running transfers occur). I really don't know how effective
> QOS is, so it may be a bad way to approach this issue.
applications set QoS (particularly to distinguish between interactive and
bulk traffic) so it can be useful to look at. For outbound packets you
are OK, for inbound not so much.
It makes it hard to handle inbound traffic which you may also need to
> If an update connection had low priority for the bandwidth resources, that
> connection should be postponed whenever a higher priority connection wants
> to push outbound traffic. A browser then would get to send its page
> requests or acks ahead of running transfer packets from the update utility;
> the result would be a much more responsive browser while still using most
> of the available bandwidth. Whether the QOS flags are being
> stripped/mangled once the traffic leaves the local machine should not
> really hurt that improvement would it?
manage. Though in a particular case that may not be a bottleneck. In your
case it looks like you will be needing to throttle inbound traffic, so
this is relevant. The way this shaping is done you either drop some packets
from the connections you want to slow down or you set bits in the
acknowledgement thay say the sender should slow down as if you had dropped
the packet. Not all network stacks support the later feature, but I don't
know what fraction do these days. It might be in practice almost everyone
does.
So you aren't blocking outbound requests in order to prevent applications
from retrieving data. That kind of approach would be a lot different and
have to be customized to each application.
>You don't really want to drop all packets, just some. The sender is supposed
> I'm just thinking it may not require full end-to-end to enjoy some benefit.
> The incoming connection would not be slowed or postponed to let the browser
> respond, but by not acking what comes in until the outbound clears up I
> think it might help anyway.
to back off with an exponential reduction in send rate until packets stop
getting dropped. If you block all of them, the application will likely assume
the connection has been broken and stop working. Generally throttling and
giving priority to low latency packets should work fairly well.
Tools like tc and tcng implement queues to control outbound data. Is there any similar _kind of_ option available for inbound data?
(Obviously we can't have queues because once the packet has been received must be processed)
--
Regards,
Sunil Ghai
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
