Subject: [AVT] Multiplexing RTP based on SSRC

From: Stephen Casner <[email-masked]>
Date: Wed, 13 Mar 2002 19:46:24 -0800 (PST)

I put an item "Multiplexing RTP based on SSRC" at the end of the AVT
agenda that I'd like to discuss here on the list and in Minneapolis if
we have time.  This stems from a question asked of me by an AVT
participant after the end of the last meeting.  (I think it was Sasha
Ruditsky, but I'm not sure.)

The question was why an "RTP session" is defined by:

    destination network address
    destination port pair for RTP and RTCP

rather than:

    destination network address
    destination port pair for RTP and RTCP
    SSRC ID (which is associated with the source, not destination)

The main reason is that sessions may have multiple sources.  This is
particularly true for multicast sessions, but may also be true for
unicast sessions.  The usual implied semantics for multiple audio
streams sent with different SSRC IDs in one RTP session (same
address/port) is that they should all be mixed together for playback.
On the other hand, that behavior is not mandated anywhere; it is
application-specific.  Some applications never have more than one
souce per RTP session.

Restated, the question is, "Why should multiplexing of RTP sessions
based on the SSRC ID be disallowed?"  Section 5.2 in the RTP
specification (draft-ietf-avt-rtp-new-11) discusses the multiplexing
of RTP sessions and says that multiplexing of separate audio and video
streams SHOULD NOT be based on the payload type or SSRC ID fields.
Five reasons are listed.  This section is primarily addressing the
question of multiplexing an audio stream and a video stream in one RTP
session, but it would also apply to the multiplexing of two unrelated
audio streams.  A general principle is stated that the number of
multiplexing points should be minimized, and that for RTP the
multiplexing is provided by the destination transport address (network
address and port number).

The context of the particular question was for a gateway or proxy
receiving many unrelated streams of audio.  The stated problem was
that operating system performance degraded severely when many streams
were being received on separate UDP ports (separate sockets).  So, the
question was why not allow these streams to be received on a single
UDP port (pair) and multiplex them based on the SSRC ID?  Of the five
reasons given in Section 5.2, the first three apply to using one SSRC
and multiplexing (say audio and video) using the payload type.  The
last two also apply to multiplexing on the SSRC ID.  They are:

    4.   An RTP mixer would not be able to combine interleaved
	 streams of incompatible media into one stream.

    5.   Carrying multiple media in one RTP session precludes: the
	 use of different network paths or network resource
	 allocations if appropriate; reception of a subset of the
	 media if desired, for example just audio if video would
	 exceed the available bandwidth; and receiver
	 implementations that use separate processes for the
	 different media, whereas using separate RTP sessions
	 permits either single- or multiple-process implementations.

The claim is that none of these considerations applies to the case of
this gateway/proxy application.

So, the question we (AVT) need to address is whether the RTP
specification should be changed to address this problem.  Should we
consider modifying the definition of an RTP session so that the SSRC
ID may be included in the tuple under some conditions?  If so, what
conditions?

Recognize that if multiple independent sources are going to send
packets to the same destination address/port, then the assignment of
SSRC IDs to those sources must be coordinated.  Should this mode of
operation be predicated on the existence of a session setup protocol
that allows the SSRC ID to be assigned by the receiver?  Or is SSRC ID
collision detection and resolution sufficient?  What would be the risk
of interoperability impairment?  Perhaps this mode of operation would
require the creation of a new RTP profile which redefines the RTP
session tuple and specifies a receiver-based mechanism for SSRC ID
assignment.

Taking off my co-chair hat, my position is that we should avoid making
any changes to draft-ietf-avt-rtp-new-11 other than bugfixes what may
be required as a result of the IESG Last Call and review.  Creating a
new profile would be a feasible course of action that would not delay
progress on the main spec.

But I ask, what is the real problem here?  Poor OS performance in
demultiplexing based on UDP port numbers.  Some implementations
assumed that only a few ports would be used, and therefore do a linear
search.  A hash function would solve the problem easily.  Wouldn't it
be better to fix the OS rather than bending the protocol?

							-- Steve

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 14 Mar 2002 08:55:10 +0200

Steve,
First of all I would like to agree that if the problem is the OS or IP stack
then it should be fixed. The proposal is to allow multiplexing of streams
coming from different sources. that is different then multiplexing streams
from the same source.
As for the issue. If we multiplex stream coming from different sources, even
if they are of the same type this may have network implication both on
security and QoS that base their policies on the address/port pair.
The other reason is as stated in the RTP draft and is tied to the first one
is to reduce the multiplexing layers. 
Regards
Roni Even

> -----Original Message-----
> From: Stephen Casner [mailto:[email-masked]]
> Sent: Thursday, March 14, 2002 5:46 AM
> To: AVT WG
> Subject: [AVT] Multiplexing RTP based on SSRC
> 
>