Subject: RE: Admission Control

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Wed, 1 Dec 1999 07:53:52 -0800

> But what is the end of this approach? Now you are talking of the 
> inbound network stack as the sender to the application...later 
> you can think of a 'sender' in the application program itself...a
> scheduler giving packets to different data collecting points. So 
> I see no end of this approach.
> 

If you wish to structure your application to control the priority at which
it handles different data flows between various components of itself - be my
guest. My concern is to make sure that the network stack in the OS delivers
received trafic to the application in a manner that suits the needs of the
application. 

For example - in a videoconference app, it is possible that the receiving
network stack will become congested. I want to make sure that control
traffic gets to the receiving app above all other trafic. Next, I would
probably want to get my audio through and finally, the video. It may be that
I need to prioritize access to resources in the receiving network stack to
accomplish this.

Y

---

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Sun, 5 Dec 1999 18:41:41 -0800

> The idea is that the path from the receiver's NIC through the IP stack
> is one of limited resources, which reservations can be made on.
> 
> In fact, this is a reasonable assumption, because many hosts 
> (especially
> PCs) do not have a stack (or bus architecture) efficient enough to
> provide a stream of packets to applications at the full line rate of a
> 100Mbps or faster interface.
> 

And even as these busses and stacks get faster (Win2K :-)... the apps will
get faster. And anyway, for audio, one has to be concerned with resources
required for instantaneous latencies, not just average bandwidth. So - it
will always be helpful to prioritize the amount of receive resources in the
stack that are aailable to different application flows.

> Going beyond that (within the application) probably doesn't make sense
> unless its design creates yet another resource shortage which must be
> managed.

I agree.
> -- David