Subject: New (???) resource reservation idea

From: Michael Welzl <[email-masked]>
Date: Tue, 10 Jun 1997 16:56:24 +0200

Hi everyone,

My idea is very simple, but to me it really makes sense.
It's about musical collaboration. Musical collaboration means, above all,
you need a guaranteed delivery time; that makes musical collaboration
just an example of human interaction, as most people I know of complain
about the time delay you get when videoconferencing.

Getting rid of a certain latency time means reserving a certain PATH
and a certain BANDWIDTH along that path (Might be a "virtual path"
as in ATM, too).

Now I strongly believe that such things could only be made by going
for it in a very cautious way. All approaches to bandwidth and or
route reserving I ran into so far seem to be pretty "brutal", though.

Isn't it a lot better to actually have something that works but
is very, very restrictive than having nothing at all ?
I'd rather have an application that might not work at all due to
the present net traffic or my location than have no application
at all, so in my opinion, that's the way to go for it.

Having that concept in my mind, I tried to find how big the smallest
amounts of data for musical collaboration should be, and believe it
or not, you could jam together using a maximum of 4 voices and 2
octaves (which is pretty restrictive indeed, but not even close to
the restrictions the first synthesizers had - and still, they were
used) by transmitting just TWO bytes !!!

Therefore, I created a very simple data format called MINI that
encodes about anything you need for very basic musical interaction
with two bytes. It offers various modes, so you could decide to
go for more octaves and less voices instead, for example.

This data format could even be implemented as an adaptive protocol:
An application could ASK how much bandwidth it will get and then
use the appropriate version of the protocol.

Let me explain my vision using a scenario:
Application A wants to send musical data to Application B and
therefore needs to ask if it's possible to transmit as much
data as it would like to, using a specific protocol. The answer
could be "yes", "no", "you don't get THAT much bandwidth. you
can have xxxx bps instead.", "latency time's going to be a little
more than you had wanted - probably about xxx s", or both of the
last two messages. Then, the application could ask the user if he
will live with less bandwidth and/or more delay or if he'd rather
forget about it.
Should the user then accept the new conditions, a version of the
MINI musical data format will be used that needs even less data.
(Which could mean to have just 1 voice, for example)

Let's say traffic increases. The protocol for bandwidth and route
reservation could then make the user decrease the sent data or
just interrupt the reservation.
Why not ? I'd still rather have a reserved route and bandwidth
that could be interrupted anytime than have NOTHING at all !!!

What would you say about that ?
Would this be possible ? I think so !
Is there a protocol that already allows doing this - or something
similar ? Or are they _ALL_ as "brutal" and demanding as RSVP
seems to be ?

I would be _VERY_ glad if someone could give me a little
feedback on all this,

so long,

Michael Welzl