Subject: Proposal: New QoS type !

From: Michael Welzl <[email-masked]>
Date: Fri, 20 Jun 1997 13:13:45 +0200

Some applications need a guaranteed maximum latency more than
anything else; just think of an interactive-MIDI-music - program.
To provide latency, bandwidth reservation is necessary.

To stick to the topic of musical interaction, a data format
similar to MIDI could be made adaptive, so less bandwidth
would mean something like "less octaves" or "less voices".

What we now need is a QoS type for applications with
variable bandwidth (I'd call it "Variable Load") that would
allow routers to put the other traffic's priority ABOVE
the stream's priority instead of vice versa.

This goes along with the concepts about adaptive
compression presented in Huitema's books, "Routing In
The Internet" and "IPv6 - The New Internet Protocol".

The only difference to _NOT_ reserving bandwidth at
all would be that the application would KNOW how much
bandwidth is currently availabe; the router could simply
cancel the reservation so that the app would have to
try again.

The benefits ? The app could ASK the user if he'd like
to continue with less bandwidth and then make a well
defined transision to less octaves and voices in our
musical example, still keeping guaranteed latency.

Now some of you might say this would probably lead to
streams that would be interrupted or just refused all
the time. Well, first, I'd rather live with _VERY_ little
reserved bandwidth (AND latency !) than with none at
all. When the first synthesizers came out, nobody
worried about the fact they were monophonic. It was
still better than having nothing at all.

Second, due to its adaptive nature, as the overall
net bandwidth increases, so does the allowed reservation !!!!

I'm serious, why not give it a try ?

greetings,
Michael

---

From: Andrew Campbell <[email-masked]>
Date: Fri, 20 Jun 1997 14:01:03 -0700

Michael:

A few years ago we implemented an "adaptive network service"
which supported multi-resolution video flows. The base
layer (min QOS) was given hard guarantees and the enhancement
layers (value added QOS) 'soft guarantees'. We used the
now defunct ATM technology ;-) as our network; the service
was similar in nature to ABR. 

For detailed results of our prototype see:

Campbell, A.T. and G. Coulson, "QoS Adaptive Transports: 
Delivering Scalable Media to the Desk Top", IEEE Network, March 1997

or URL

http://comet.ctr.columbia.edu/~campbell/andrew/publications/publications.html

We are applying a modified version of this service to the
wireless domain as part of a QOS-aware middleware platform
for mobile multimedia networking called "mobiware" - see 
http://comet.ctr.columbia.edu/wireless/ for details.

I think there is room between controlled load and guaranteed
delay for maneuver!

Andrew

--
Andrew T. Campbell  
http://comet.ctr.columbia.edu/~campbell
Wireless Media Systems Project 
http://comet.ctr.columbia.edu/wireless

---

From: Andrew Campbell <[email-masked]>
Date: Fri, 20 Jun 1997 14:01:03 -0700

Michael:

or URL

Andrew

---

From: Andrew Campbell <[email-masked]>
Date: Fri, 20 Jun 1997 14:01:03 -0700

Michael:

or URL

Andrew

---

From: Andrew Campbell <[email-masked]>
Date: Fri, 20 Jun 1997 14:01:03 -0700

Michael:

or URL

Andrew