[e2e] Data flow models for real-time applications

[Detlef Bosau]

I have to admit, that I'm somewhat confused by your question.

On the one hand, there is an incredibly huge amount of work which deals 
with realtime applications for streaming video.

Actually, the amount of work is that huge that I'm really surprised that 
you want to start a PhD project in this area. There might be a gap left 
- but it would perhaps require 10 PhD projects to find it.

On the other hand, and I tried to work in that area myself some years 
ago, this kind of work is somewhat frustrating.

The point is that the Internet is 1. a packet switching network and 2. 
should be able to work without central ressource management. (Precisely: 
"must
permit distributed management of its ressources".)
(D. D. Clark, "The Design Philosophiy of the DARPA Internet Protocolls", 
SIGCOMM 88)

Actually, I don't see  that real time streaming will easily fit into 
this philosphy.

Of course, there _are_ attempts of fitting streaming into IP.

The Streamint Protocol ST II was already mentioned.
http://www.isi.edu/in-notes/rfc1819.txt

Surely, you want to look at the Tenet suite by Ferrari et al.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.4645

(As you easily see, this work dates bake into the early 90s. That was 
the time of the "Multimedia Hype" in the Internet.)

And of couse, you will have a look at the "Intserv" work.

And of course one of the most important works in this area is the PhD 
dissertation by Srinivasan Keshav, 1991
http://www.cs.cornell.edu/skeshav/doc/keshav.th.tar.Z

At least the multimedia streaming approaches build a circuit switching 
upon IP, which basically requires negotation and reservation of 
ressources from the sender to the receiver.

So basically, these works provide a careful and convincing proof, that 
IP packet switching can be used in the same way as ATM cell switching or
other approaches from the telephony world.

My first concern is: This is nothing new. We all know, that ATM works.
My second concern is: Is this really, what we want?

Particularly, Keshav's work points out that there _is_ some kind of 
ressource management necessary, which can be implemented in a 
distributed manner of course, but what was Clark's intention? A 
hierarchical approach? Or a heterarchical approach?

In the case of a heterarchical intention, the whole thing appears to me 
like some kind of "abuse" of the Internet: Why shall we use a packet 
switching service, which is intended to be a best effort, heterarchical, 
asynchronous service as a replacement for a TDMA service? And what is 
the purpose to prove that peaches can be taken as oranges?

For me, another concern is important. When I worked in this area, I 
dealt with mobile networks. And I was expected to build an 
"architecture" for "QoS" etc. with mobile networks.

To make a long story short: QoS parameters like "bit rate", "bit error 
ratio" and the like cannot be mapped onto physical parameters in a UMTS 
link or the like, even if you consider only one link.

Period.

Actually, media streaming / voice transfer in mobile networks, 
particularly with QoS support like UMTS, is basically line switched 
/TDMA switched
and follows different paradigms than packet switching. And this makes 
sense: As we all know, we _can_ talk to each other with cell phones.
And there is absolutely no reason to reinvent the wheel here with packet 
switching for the one and only reason that we are not willing to see 
that different technologies are well suitable for different purposes.

So, if my post sounds a bit frustrated, the reason is: I _am_ frustrated 
an this matter, and I really wonder why you really start a work which 
has been done
15 years ago and which lead to quite a few "demo implementations" in 
universities where it was carefully proven that we can achieve
"QoS by underutilization" and that we can do video streaming from one PC 
to another - iff the GE back to back cabling between them was "big and 
fat enough", while in the commercial industrie, there was a certain 
episode with "speeach conference systems" and "multimedia audiovisual 
cnference systems" (namely by Intel and Sony) and the like which lasted 
IIRC less than five years.

In the late 90s, these systems were some kind of status symbol for 
"managers" and "decision makers", but I always saw them unused, because 
no decision maker really wants to abstain from the inevitable "meetings" 
and "buisness trips". So, the argument was to buy a conference system in 
order to spare costs - and the reality was that the bill was to be paid 
for both: The conference system and the buisness trip as well.

(We all know the fortune cookie: Do not hesitate any costs to spare on 
this one!)

Detlef





Guy - Alain Lusilao-Zodi wrote:
> Hi All,
>
> I am working on a project which consist of developing an end-to-end 
> quality of service for real-time applications. The novelty of the 
> project is to develop an instantaneous model of flow for real-time 
> applications or for streaming video.
> I would like to known if no one have never try to develop a model of 
> flow for real-time applications that can server as a basis for my 
> project.
> Also as PhD degree, this is suppose to be my contribution, therefore 
> if the work have already been done I will appreciate if you can 
> provide me the necessary informations otherwise I will be wasting my time.
>
> Regards
>
> -- 
> ----------------------------------------------------------
> G.-A. Lusilao-Zodi           voice : 0216554019
> PhD in Video streaming  cell    :082687993                             
>      
> Communication group    guylzodi at gmail.com <mailto:guylzodi at gmail.com>    
> university of cape-Town
> -----------------------------------------------------------


-- 
Detlef Bosau                          Mail:  detlef.bosau at web.de
Galileistrasse 30                     Web:   http://www.detlef-bosau.de
70565 Stuttgart                       Skype: detlef.bosau
Mobile: +49 172 681 9937

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3351 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20090218/16e7d1ca/smime.bin