Seems like what you want is a set of knobs that the user can tweak: one
knob to say the max bandiwdth this computer should use (in case you have a
small group sharing an ISDN, DSL, or T1 line or something), and a bunch of
knobs - maybe one per window - to control what fraction of that bandwidth
goes to different flows (the real audio session vs your download of Duke
Nukem 8.0 vs Point Cast vs cnn.com), as well as a "don't care" button
somewhere.
Suppose the user sets the Netscape knob to 10Kbps, in order to leave at
least 18.8 for real player at all times. Then, when the user clicks on
cnn.com, the OS notifies real player that it's going to see service
degrade down to 18.8 for a while . In addition, the OS takes special steps
to rate-limit the web browser's bw usage to 10Kbps, by tuning down the
receive window and clocking out ACKs slower; maybe even lowering the MSS
negotiated at connection setup time. When the web page download is over,
the OS tells real player "expect to see bw go back up to 28.8". Note that
dropping packets at the client won't quite work, because if you just give
drop signals to TCP, it will just send bursts, using up queue slots that
should go to audio packets.
I suppose you could also do something similar with a wart, by sending the
knob values to the wart.
Have people looked at this sort of thing? It seems different from RSVP and
CBQ.
neal