Updates using idle bandwidth

Ahmed Kamal email.ahmedkamal at googlemail.com
Mon Mar 24 13:42:38 UTC 2008


lartc mentions ways for "traffic policing" to throttle incoming rates
by throttling outgoing ack packets

2008/3/24 Sunil Ghai <sunilkrghai at gmail.com>:
>
>
>
> On Wed, Mar 12, 2008 at 11:50 AM, Bruno Wolff III <bruno at wolff.to> wrote:
> >
> > On Wed, Mar 12, 2008 at 01:59:46 -0700,
> >  Andrew Farris <lordmorgul at 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 at redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>




More information about the fedora-devel-list mailing list