Subject: mail rispedita-il ccds

From: [email-masked]
Date: Thu, 26 Jun 1997 13:25:05 +0200

Received: from localhost (localhost) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with internal id EAA17995; Tue, 24 Jun 1997 04:49:36 -0400 (EDT)
Date: Tue, 24 Jun 1997 04:49:36 -0400 (EDT)
From: [email-masked] (Mail Delivery Subsystem)
Subject: Returned mail: <[email-masked]>... aliasing/forwarding loop broken
Message-Id: <[email-masked]>
To: <[email-masked]>
Auto-Submitted: auto-generated (failure)

The original message was received at Tue, 24 Jun 1997 04:49:07 -0400 (EDT)
from tovvx1.ccd.utovrm.it [160.80.1.5]

If you need help interpreting this error message, please first ask a
knowledgeable person or postmaster at your site.

				 Sincerely,
				-Postmaster General
				 Center for Telecommunications Research
				 Columbia University

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>
:include:/proj/argo/comet/exploders/wireless
    (expanded from: <[email-masked]>)

   ----- Transcript of session follows -----
550 :include:/proj/argo/comet/exploders/wireless... Cannot open /proj/argo/comet/exploders/wireless: No such file or directory
Message delivered to mailing list <[email-masked]>
554 <[email-masked]>... aliasing/forwarding loop broken

   ----- Original message follows -----

From: [email-masked]
Date: Tue, 24 Jun 1997 10:38:30 +0200
To: [email-masked], [email-masked]
Subject: mail rispedita - il ccds

Date: Fri, 20 Jun 1997 14:01:03 -0700
From: Andrew Campbell <[email-masked]>
Reply-To: [email-masked]
Organization: Ceter for Telecommunications Research, Columbia University
To: Michael Welzl <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposal: New QoS type !
Sender: [email-masked]

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

Michael Welzl wrote:
> 
> 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

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