Updates using idle bandwidth

Sunil Ghai sunilkrghai at gmail.com
Tue Mar 25 08:29:18 UTC 2008


On Mon, Mar 24, 2008 at 2:14 PM, Sunil Ghai <sunilkrghai at gmail.com> wrote:

>
>
> On Mon, Mar 24, 2008 at 11:14 AM, Bruno Wolff III <bruno at wolff.to> 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?
> >
> > Yes and a protocol change was made to help. I believe this is the
> > purpose of
> > ECN (explicit congestion notification).
> >
> > > > 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)
> >
> > Shaping on the wrong side of a link is problematic. You can implement
> > queues
> > on the receiving side which might allow you to better control which
> > flows
> > get slowed down using IFBs (which replace the older IMQs). While you
> > can't
> > absolutely prevent the other side from swamping the link with low
> > priority
> > packets, things should work reasonably with well behaved applications.
> >
> >
> Ingress shaping...sounds good!
> Basically it is the way to implement policing efficiently?
> --
> Regards,
> Sunil Ghai


For traffic accepted on an interface, the *ingress* qdisc is traversed. It
means all inbound data is traversed through it. So how do we differentiate
as which inbound packet is for which application?  port numbers? and who
does it..operating system of *filters* attached with *ingress qdisc*?

If we want to implement policing on a particular connection, it's inbound
packets may be dropped. But as *ingress qdisc* is common to an interface so
how do we implement it?


-- 
Regards,
Sunil Ghai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080325/54849289/attachment.htm>


More information about the fedora-devel-list mailing list