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