Subject: RE: Container files and various methods of dealing with them

From: Brad Hefta-Gaub <[email-masked]>
Date: Wed, 25 Jun 1997 22:28:06 -0700

Steve, A couple of days ago you replied to a mail message by talking about
a container file "...being streamed as one "homogenous blob"..." I assumed
that you were referring to the above description. Namely that when a container
file is being streamed in it entirety (as a presentation) then it makes sense
to stream it as a blob to a single port. 

Can you explain to the group what you meant?

>> 
>> > 1-1-1 has always been possible, and that is how PN plans to stream
>> > container files.  The way that this is done in unicast is that the streams
>> > are multiplexed using the SSRC, and the SSRC values are enumerated in the
>> > session description.  It would probably be a good idea to do a more
>> > rigorous definition of this.  If necessary for multicast, we could have
>> > separate SSRC and a new field (added via standard RTP mechanism) so that
>> > the SSRC selection and the stream id don't get mixed up.  A more rigorous
>> > writeup is needed here.
>> 
>> I think this is a bad idea.  Section 5.2 of the RTP spec argues
>> against multiplexing multiple media into one RTP session for a list of
>> reasons.  Perhaps you could discount some of these for the unicast
>> case, but I think creating an RTP implementation that works only for
>> unicast is short-sighted.  Forcing SSRC id's to go into the session
>> description seems like a bad move to me.

The 1-1-1 is a proven model. RealVideo, NetShow, V-Xtreme and VDO
(to name a few) all use this technique. Firewall authors will clearly prefer a
technology that implements 1-1-1 since it allows for straight forward 
implementations that associate single UDP sockets with a single control 
session.

It seems our goal as a group should be to define how we will make this
1-1-1 case (aka "homogeneous blob") correctly interoperate. I would 
prefer to see us not waste the SSRC field of the RTP header, but as Rob 
points out we could leave SSRC the same for all streams from the container
and use an extended RTP field to store the demultiplexing information. This 
seems like a real waste of bits to me.

I also think you're stretching a bit on the claim that this model breaks down
for multi-cast. It in fact does _not_ break down for multicast, as you should
note that many of the products I mentioned above also support multicast and 
I'd suspect they use a similar packet format (if not identical format) in the 
multicast and unicast cases. 

The real issue of using SSRCs as presented by Rob would be for the multiple 
sender case. It seems to me that the multiple sender case is out of the scope 
of RTSP. I believe the group has agreed for example that gateways should 
be used to "stream into conferences" and as such, the gateway can solve 
the SSRC mapping.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: [email-masked]
web:   http://www.real.com
-----------------------------------------

---

From: Stephen Casner <[email-masked]>
Date: Thu, 26 Jun 1997 19:27:36 -0700 ()

Brad,

> to stream it as a blob to a single port. 

I quoted the term from the message to which I replied.  I was
referring to the transmission of a container file, such as an MPEG1
Systems Stream, or an ASF file as Eric Fleischman has argued for on
several occasions, as one RTP stream.  In this case, the container
file is already pre-multiplexed and chunks of it are transmitted as-is
across the network.  The primary motivation I have heard for this mode
of operation is to support large servers that cannot afford to do any
manipulation of the data coming from the file.

If the server can afford to manipulate the data, for example to pull
individual streams out of a container file (AVI, ASF, Elementary
Streams out of an MPEG System Streams file, or whatever), or if the
data is stored in separate files as Anup noted in his followup
message, then I argue that separate RTP sessions should be used for
the reasons discussed in the RTP spec:

  - An RTP mixer normally combines all the SSRCs it receives on an RTP
    session according to the composition method that is appropriate
    for that session (e.g. mixing for audio).  If multiple media are
    sent on one session, then the SSRCs must be segregated per medium
    based on external information.  That gets complicated with sources
    coming from multiple places.  It is similarly more complicated for
    and end node receiver to handle streams coming from multiple
    sources to the same RTP session if some of those sources don't all
    get fed to the same compositor (mixer, selector, whatever).

  - Carrying multiple media in one RTP session precludes the use of
    different network paths or network resource allocations if
    appropriate.  For the typical synchronized audio/video stream one
    may not want different paths, but it is not hard to imagine
    situations where one medium should go via a low-bandwidth,
    low-delay terrestrial path while another can tolerate the longer
    delay of a satellite path in order to get higher bandwidth.

  - Carrying multiple media in one RTP session precludes reception of
    a subset of the media if desired, for example just audio if video
    would exceed the available bandwidth.  This is not an issue for
    unicast since that choice of media would be controlled by the
    exchange with the sender, but it is valuable for multicast with
    heterogeneous receivers.

  - Carrying multiple media in one RTP session precludes receiver
    implementations that use separate processes for the different
    media, whereas using separate RTP sessions permits either single-
    or multiple-process implementations.  Consider the development of
    "desk area networks" at MIT, ISI and other places in which the
    display and the speaker may have different IP addresses.  This is
    an instance of the general philosophy of demultiplexing at the
    lowest level possible.

  - Also, making the SSRC fixed is a problem in the multicast case
    because collision resolution might require changing the SSRC id.

It is harder to accept these arguments if you don't believe multicast
is important.  But consider that RTSP might be used to stream material
into a teleconference, for example.

> implementations that associate single UDP sockets with a single control 

The hard part of feeding this data through the firewall is that you
need to communicate a UDP port number to the firewall and have an
association with a control session.  If you can communicate one port
number to the firewall, it is very little more work to communicate (or
store) several.

> seems like a real waste of bits to me.

For the already multiplexed file, this latter method is essentially
what happens, but in that case it is preferred (by some) because of
the reduced data handling.  I agree that wasting bits for additional
demultiplexing information is not good.  I'm arguing for using
existing lower-level demultiplexing information.

> multicast and unicast cases. 

The multicast case you're considering is probably when there is only
one server sending to a multicast session.  When there are multiple
sources sending into a session, then keeping track of which SSRCs
belong to which of the logical RTP sessions that are squeezed into one
real RTP session is messy.  You are right, it could be done, but are
there benefits sufficient to make that choice worthwhile?  The
difficulty with this discussion is that there is none of this that
couldn't be made to work one way or another.  It's a matter of
tradeoffs: optimization for a specific function vs. generality.  I'm
arguing for keeping the mechanisms for dealing with multimedia RTP
sessions the same across a range of RTP-based applications so that
when those applications bump into each other, as they surely will, we
don't get sparks.

This becomes more important when considering not just a particular
vendor's server talking to that same vendor's client, but also
interoperation of components from multiple vendors.

What are the costs you want to avoid with the 1-1-1 model?  Number of
sockets at the server?  What are the real limitations?

> be used to "stream into conferences" and as such, the gateway can solve 

I don't recall that the group has agreed gateways should be used.
When was that?

Again, my point is that it is best to avoid making the single sender
case different from the multiple sender case unless we are really
forced to do so.
							-- Steve

---

From: Stephen Casner <[email-masked]>
Date: Thu, 26 Jun 1997 23:26:35 -0700 (PDT)

There were two other points I forgot to make:

  - Even in 1-1-1, there would be more than 1 UDP port number unless
    you intend to specify that RTCP is not used and that
    synchronization is to be done by some other means.

  - If it is agreed that 1-n-n needs to be supported for some cases,
    then I claim it is better not to specify 1-1-1 as well since 1-n-n
    is a "superset" of 1-1-1 in some sense.  Having lots of options
    and lots of flexibility is a not a good design goal for a
    protocol; it complicates implementations, increasing the
    probability of errors, and it decreases the probability of
    successful interoperation of multiple implementations.

							-- Steve