Subject: Re: In Defense of Interleaved Data Formats

From: Ross Finlayson <[email-masked]>
Date: Wed, 5 Mar 1997 21:54:48 -0800 (PST)

At 03:05 PM 3/5/97 -0800, Eric Fleischman wrote:
>4.	Disk-head movement efficiency on the server. The argument here
>is that interleaving encourages more efficient disk storage approaches
>with superior I/O processing capabilities. This directly effects the
>construction of more efficient network streaming approaches. This
>efficiency directly translates into server performance including the
>ability to support a larger number of simultaneous "On-demand" sessions
>by that server.

Let's not forget that we're designing network protocols here, not storage
formats.  There's nothing to preclude the various media that make up a
multimedia session being interleaved on the *disk*, even though the data
within each of the resulting network packets is not interleaved.  (In fact,
one can even imagine a media server storing its data with partially
precomputed network headers, to optimize the process of spitting its data
out onto the network.)

Incidentally, this confusion - between storage formats and network data
formats - is one that I've seen recently occur in other IETF working groups,
e.g., the "calendar scheduling" group.  Microsoft (& other companies) are
free to continue to define and use whatever storage formats they wish.  We
don't care; this is the *Internet* Engineering Task Force.  All we care
about is what goes over the network.

In your follow-up message, you wrote:

>It is doubtful that you will be able to understand what I'm talking
>about as long as you think as an engineer. I am talking "experience" not
>"information". This is a left-brain, right-brain type of dichotomy. To
>understand what I'm saying, you have to think as an artist. What we are
>talking about is the preservation of an artistic creation across the
>network. That this creation may educate or convey critical, essential
>information does not diminish the fact that we are talking about
>art-forms when we are talking about "on demand" streaming.

I'm sorry to sound rude, but this "touchy-feely" stuff makes me want to
vomit.  This is the Internet *Engineering* Task Force, and *engineering* is
what we do here.  Fortunately, there *are* some real engineering questions
that arises from your concerns, namely:

You want it to be possible to implement one of the following end-to-end
semantics when confronted with network loss or delay:
        1/ cancel the presentation
        2/ delay the presentation (as appropriate)
        3/ continue the presentation in spite of missing data
The questions are:
a) Can the particular choice (between 1, 2 and 3) be adequately conveyed -
e.g., in a session description - if different media are *not* interleaved
within network packets.
b) Can each of these choices be implemented (efficiently), if different
media are *not* interleaved within network packets.

We should, I think, be able to answer these questions without having to
stick our heads inside a pyramid.

        Ross.

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 06 Mar 1997 09:13:44 +0000

>media are *not* interleaved within network packets.
 
yes, well said...

actually, what interleaving says is :

It is a REQUIREMENT of this type of presentation that all media suffer
network effects exactly in proportion to the way they are interleaved....

since this is pretty arbitrary compared with the way the QUALITY of
the presentation will then vary (e.g. consider a variation in rate or loss
for video versus a variance in audio for a given relative sample size
in the packet), i suspect most content providers would be fairly upset
by the way such a presentaiton would degrade......

interleaving: lets see now, what was the end2end principle again?

 >stick our heads inside a pyramid.

:-)

 jon

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Mar 1997 08:05:23 -0500

It should be pointed out that we had this same discussion many moons
ago, on the rem-conf list, at least once. Note that there is one
interleaved MPEG format (Civanlar) already.
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 7 Mar 1997 23:16:09 +0200 (EET)

> >4.	Disk-head movement efficiency on the server. The argument here
[snip]
> e.g., the "calendar scheduling" group.

This is a direct consequence of trying to make things simple: the most
basic server conceivable is the one that just spits out the data it has.
(Say, HTTP...)

>         2/ delay the presentation (as appropriate)

1-2 seem partially equivalent. Just as in the PAUSE issue.

> e.g., in a session description - if different media are *not* interleaved

The easiest way to go would be to add a single word (such as those
'encrypted' and other pseudo terms the current draft uses) to indicate the
type for each track (session?).

> media are *not* interleaved within network packets.

When fighting congestion, one shouldn't assume the client can do anything
extra. So it's all about server throttle-back. So these semantics need to
conveyed to the server when initiating a stream. This approach isn't
dependent on whether the data is interleaved or not.

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>