RFC - bandwidth optimization idea

Linux Advanced Routing and Traffic Control

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

 



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.
_______________________________________________
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