Re: RFC - bandwidth optimization idea

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 08, 2005 at 08:55:08PM -0700, Don Cohen wrote:
> 
> I'm interested in all of
> - opinions about why this is a good or bad idea
> - pointers to similar proposals or products that already exist
> - implementation suggestions

> This is meant for real time applications that have small available
> bandwidth and so they have to consider carefully what's the best way
> to use that bandwidth.  I imagine that things happen that cause them
> to continually reevaluate what's the most important/urgent thing to
> send next.  I want to make it possible for them to delay the choice
> until the OS is actually ready to send that next packet.  The reason
> they can't do this now is that the OS enqueues packets.  Suppose an
> application uses udp or tcp to tell the OS to send some data.  It then
> discovers that data is obsolete.  The old data might still be in the
> queue to be sent but it's too late to recall it.  One way to avoid
> that is to always delay telling the OS to send something until the OS
> is almost ready to send the next packet from the queue that your data
> will enter.  But that's not so easy to do, and there's a big penalty
> if you wait just a little too long.  What I want, at least
> conceptually, is that the application maintains its own queue of data
> to be sent, ordered by priority.  Whenever the OS is ready to send the
> next packet for that application, it removes the highest priority
> packet (if any) from the queue and sends it.

I believe the general solution to this is to use UDP, and make sure
your source machine doesn't queue up packets locally (eg. ethernet
network contention) and let the best-effort nature of UDP deal with
dropping stuff that gets delayed.

I'm not sure there's any way to have an 'I changed my mind about
sending that' interface into your network stack... And generally
it wouldn't be useful, data spends longer in transit than it does
in your queues.

-- 
Paul "TBBle" Hampson, on an alternate email client.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux