lartc mentions ways for "traffic policing" to throttle incoming rates by throttling outgoing ack packets
2008/3/24 Sunil Ghai sunilkrghai@gmail.com:
On Wed, Mar 12, 2008 at 11:50 AM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 12, 2008 at 01:59:46 -0700, Andrew Farris lordmorgul@gmail.com 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.
You would still need to write the rules that do the shaping. However some 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.
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?
It makes it hard to handle inbound traffic which you may also need to 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.
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.
You don't really want to drop all packets, just some. The sender is
supposed
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.
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?
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list