Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 3 Jun 2012 23:09:51 +0000

Please see the mail attached below that I just sent to avtcore announcing a personal ID I just submitted on the topic of media multiplexing.  I am sending this notice to rtcweb since this is the group that triggered recent work on RTP multiplexing.

I also request the rtcweb chairs consider giving me some time to present this work at next week's interim meeting if there is time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver.

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM.  Please comment.

Richard

-----Original Message-----

From: [email-masked] [mailto:[email-masked]]

Sent: Sunday, June 03, 2012 5:16 PM

To: Ejzak, Richard P (Richard)

Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository.

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   00

Title:            Media multiplexing with Real-time Transport Protocol (RTP) subsessions

Creation date:    2012-06-04

WG ID:            Individual Submission

Number of pages: 9

Abstract:

   This document describes a means of multiplexing RTP streams having

   different media types within a single transport connection and how to

   represent this multiplexing option in SDP.  This mechanism is an

   alternative to the BUNDLE and SHIM proposals currently under active

   consideration in AVTCORE.  Instead of adding an extra multiplexing

   header as in SHIM to allow multiple RTP sessions within a single

   transport connection, or using the payload type field to separate

   different media streams within a single RTP session, this document

   describes how to partition the existing SSRC space to create RTP

   subsessions from a single RTP session.  A filter can be used to

   identify each RTP subsession for different QoS handling as necessary.

   RTP subsessions can be treated like RTP sessions with a few

   restrictions.  In particular, SSRC mapping may be needed when

   forwarding RTP streams into an RTP subsession to avoid SSRC

   conflicts, but there are few use cases in which this limitation is a

   concern and RTP subsessions can be disabled if necessary.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 09:22:34 +0200

Hi Richard,

I will not comment on the RTP aspects of your proposal, but I don't understand your comments regarding BUNDLE.

The core purpose of BUNDLE is to allow the usage of identical IP address:port information for multiple m- lines.

It is true that BUNDLE defines that, by default, all media belong to the same RTP session. But, nothing prevents you from using BUNDLE also with multiple RTP sessions, RTP "subsession" etc. You simply need an extension mechanism  to indicate/negotiate such usage (in your case the ssrc-prefix could perhaps be used for that).

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ejzak, Richard P (Richard)
Sent: 4. kesäkuuta 2012 2:10
To: [email-masked]
Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Revision:   00

Number of pages: 9

Abstract:

The IETF Secretariat

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 4 Jun 2012 13:33:45 +0000

Hi Christer,
I agree that BUNDLE in its current form would be consistent with the RTP subsessions proposal, but it would also be technically redundant.  I'm not sure exactly which comments in the paper you object to.  I agree with you about the purpose of BUNDLE and that it works (with limitations) for its intended purpose.  My understanding is that BUNDLE is primarily intended for the case where a single RTP session is shared across m lines.  There is no need for BUNDLE (and specifically the constrained PT assignment) when you use another mechanism such as SHIM or RTP subsessions to segregate the flows associated with each m line.  Whether the grouping framework is applicable is open for discussion.

So perhaps we should separately discuss the grouping framework and constrained PT assignment procedures associated with BUNDLE to be sure we understand one another.  The source of our disagreement may be more what is meant by "BUNDLE" than anything else.  I have no problem redefining it if there is agreement to do so!

I look forward to an in-depth discussion of these issues in Stockholm.

BR, Richard

________________________________
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 04, 2012 2:23 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi Richard,

Regards,

Christer

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:%5bmailto:[email-masked]%5d>

Revision:   00

Number of pages: 9

Abstract:

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 15:54:00 +0200

Hi,

> I agree that BUNDLE in its current form would be consistent with the RTP subsessions proposal, but it would also be technically redundant.  I'm not sure exactly which comments in the paper you object to.  I agree with you about the purpose of BUNDLE 
> and that it works (with limitations) for its intended purpose.  My understanding is that BUNDLE is primarily intended for the case where a single RTP session is shared across m lines.

That is not true. That is only the "default" that we chose, and the limitations in the draft are related to the case when you use a single RTP session - they are not related to the BUNDLE mechanism as such.

> There is no need for BUNDLE (and specifically the constrained PT assignment) when you use another mechanism such as SHIM or RTP subsessions to segregate the 
> flows associated with each m line.  Whether the grouping framework is applicable is open for discussion.

You still need something in order to use identical IP address:port values for multiple m- lines.

> So perhaps we should separately discuss the grouping framework and constrained PT assignment procedures associated with BUNDLE to be sure we understand one another. 
> The source of our disagreement may be more what is meant by "BUNDLE" than anything else.  I have no problem redefining it if there is agreement to do so!

We should separate the discussions on how the multiplexing is done on the RTP level (which I think your draft mostly focuses on) and how it is signaled in SDP.

Regards,

Christer

________________________________________

Hi Richard,

Regards,

Christer

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard) 
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

Abstract:

The IETF Secretariat

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 4 Jun 2012 14:54:55 +0000

Hi Christer,
I agree with you that we should separate the discussion of how multiplexing is done at the RTP level from how it is signaled in SDP.  My draft addresses both aspects by describing how to partition the SSRC space between m lines at the RTP level and how to signal that use in SDP using a new "ssrc-prefix" attribute.

With the use of the ssrc-prefix attribute to identify RTP subsessions it is not absolutely necessary to use the grouping framework to indicate bundling, since the ssrc-prefix attribute implicitly indicates the bundling.  These two mechanisms are compatible but redundant.

BR, Richard 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 04, 2012 8:54 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi,

Regards,

Christer

Hi Richard,

Regards,

Christer

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard) 
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

Abstract:

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 18:10:02 +0200

Hi Richard,

> I agree with you that we should separate the discussion of how multiplexing is done at the RTP level from 
> how it is signaled in SDP.  My draft addresses both aspects by describing how to partition the SSRC space 
> between m lines at the RTP level and how to signal that use in SDP using a new "ssrc-prefix" attribute.

Sure. But as far as the IP address:port re-use is concerned, I think you should use BUNDLE.

> With the use of the ssrc-prefix attribute to identify RTP subsessions it is not absolutely necessary to use the 
> grouping framework to indicate bundling, since the ssrc-prefix attribute implicitly indicates the bundling.  
> These two mechanisms are compatible but redundant.

I see no reason for having two mechanisms to do the same thing, and in general I also think we should try to avoid implicit indications. If often causes troubles later on.

Using BUNDLE would also make it easier to define fallback behavior. For example, you could say that if the SDP answerer does not support the ssrc-prefix, but it does support BUNDLE, the fallback would be default BUNDLE behavior.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 04, 2012 8:54 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi,

Regards,

Christer

Hi Richard,

Regards,

Christer

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

Abstract:

The IETF Secretariat

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 4 Jun 2012 16:35:40 +0000

Hi Christer,
I just want to be clear what you mean by "BUNDLE".  I assume here that you refer to the use of the grouping mechanism and NOT necessarily the use of disjoint payload type values?

Correct me if I am wrong:
So you propose that the SDP grouping mechanism would be used regardless of the RTP multiplexing scheme employed to indicate that some form of multiplexing is to be used and to identify which lines are grouped together.  If no other mechanism is agreed, then multiplexing based on payload type is assumed.  If ssrc-prefix values are successfully negotiated then RTP subsessions are used.  If SHIM is successfully negotiated then SHIM is used.  (This all depends on which schemes are ultimately supported.)

I have no objection to this approach in principle but am not convinced that we need to support all of these multiplexing schemes.

BR, Richard

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 04, 2012 11:10 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi Richard,

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 04, 2012 8:54 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi,

Regards,

Christer

Hi Richard,

Regards,

Christer

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

Abstract:

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 19:26:37 +0200

Hi,

> I just want to be clear what you mean by "BUNDLE".  I assume here that you refer to the use of the grouping mechanism and NOT necessarily the use of disjoint payload type values?

Correct.

> So you propose that the SDP grouping mechanism would be used regardless of the RTP multiplexing scheme employed to indicate that some form of multiplexing is to be used and to identify which lines are grouped together.

Correct.

> If no other mechanism is agreed, then multiplexing based on payload type is assumed.

Yes. The details of that, however, is something that the community will have to discuss and agree upon. My point was that it would be easier to define a fallback if we use a single mechanism for bundling m- lines together.

> If ssrc-prefix values are successfully negotiated then RTP subsessions are used.  If SHIM is successfully negotiated then SHIM is used.  (This all depends on which schemes are ultimately supported.)

Correct.

> I have no objection to this approach in principle but am not convinced that we need to support all of these multiplexing schemes.

That is a separate discussion :)

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 04, 2012 11:10 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi Richard,

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 04, 2012 8:54 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi,

Regards,

Christer

Hi Richard,

Regards,

Christer

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

Abstract:

The IETF Secretariat

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Jun 2012 20:42:32 +0200

Richard,
having scanned your draft:

- I still fundamentally think that the partition of media types into 
separate RTP sessions was a design mistake that we should seek to 
rectify, not promulgate, and additional complexity like what you propose 
for perpetuating the use of "separated" sessions is not helpful. See 
draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on 
the assumption that the SSRC space is a 32-bit flat space, I think the 
partitioning of that space into subspaces as you propose is likely to 
lead to "interesting" bugs. We should reinforce the randomness and 
flatness of the SSRC space, not partition it.

- You say "The biggest problem with BUNDLE is that it is
    difficult to partition the RTP streams associated with different
    media lines since this requires filtering on sets of payload type
    values.  RTP subsessions is superior for this purpose since it is
    only necessary to screen for a single value in the first 16 bits".
This assumes that the partitioning associated with different media lines 
is a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to 
stick with that approach.

On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote:
>
> Please see the mail attached below that I just sent to avtcore 
> announcing a personal ID I just submitted on the topic of media 
> multiplexing.  I am sending this notice to rtcweb since this is the 
> group that triggered recent work on RTP multiplexing.
>
> I also request the rtcweb chairs consider giving me some time to 
> present this work at next week's interim meeting if there is time on 
> the agenda.  It might be useful to discuss the ideas in the ID before 
> avtcore meets in Vancouver.
>
> Richard
>
> Subject: [AVTCORE] multi session 
> draft-ejzak-avtcore-rtp-subsessions-00.txt
>
> In response to the chairs' request for additional input on the multi 
> session issue, I have submitted this draft for your consideration.  
> There are superficial similarities with an expired draft from last 
> year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, 
> but my draft has a different take on the use of SSRC as the basis for 
> multi session multiplexing that I think is superior and worthy of 
> consideration as a potential replacement for BUNDLE and/or SHIM.  
> Please comment.
>
> Richard
>
> Subject: New Version Notification for 
> draft-ejzak-avtcore-rtp-subsessions-00.txt
>
> A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has 
> been successfully submitted by Richard Ejzak and posted to the IETF 
> repository.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 4 Jun 2012 20:03:51 +0000

Harald,
While ideally we should be able to maintain the entire SSRC space for use by an RTP session, the current concept of BUNDLE breaks the model by mixing what are otherwise different RTP sessions together.  The scope of an RTP session is beyond just the transport connection on which bundling is occurring (see the RTP session topology diagrams in RFC 3550).  Even though RTP packets with different payload types could potentially reuse the same SSRC value, SSRC values cannot be independently assigned per m line with the current BUNDLE scheme since RTCP packets can be identified only using SSRC values (payload type is not a field in RTCP packets).  So the bundled m lines have to share a single SSRC space, thus increasing the likelihood of SSRC collision and preventing use of the same SSRC value across m lines and ports (as some applications require).  To avoid these problems, translators implementing the current BUNDLE will generally need to do SSRC mapping anyway, so BUNDLE cannot take full advantage of the "randomness and flatness of the SSRC space".

I have read your draft and should have referenced it in my paper.  I agree that different media types should be able to share the same transport connection.  But I also see a need to be able to apply differential treatment of media types within the network.

You disagree with the need to separate packets associated with different media lines for differential treatment in the network.  Nevertheless, this issue has been raised in RFC 3550 and numerous drafts since then as a legitimate issue in certain deployments.  While I agree with you that there are significant use cases in which such differential treatment is not necessary, there are others in which it can be very beneficial.  It would be really unfortunate if there were no way to support such use cases in rtcweb.

Richard

________________________________
From: Harald Alvestrand [mailto:[email-masked]]
Sent: Monday, June 04, 2012 1:43 PM
To: Ejzak, Richard P (Richard)
Cc: [email-masked]
Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE

Richard,

- I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it.

This assumes that the partitioning associated with different media lines is a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach.

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]<mailto:[email-masked]>'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Revision:   00

Number of pages: 9

Abstract:

The IETF Secretariat

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Jun 2012 08:49:53 +0200

On 06/04/2012 10:03 PM, Ejzak, Richard P (Richard) wrote:
>
> Harald,
>
> While ideally we should be able to maintain the entire SSRC space for 
> use by an RTP session, the current concept of BUNDLE breaks the model 
> by mixing what are otherwise different RTP sessions together.  The 
> scope of an RTP session is beyond just the transport connection on 
> which bundling is occurring (see the RTP session topology diagrams in 
> RFC 3550).
>
Yes, all parts of the RTP session need to agree on where the limits of 
the RTP session are. BUNDLE (the way it's currently written; Christer 
and I disagree on whether there is value in extending it to multiple 
sessions on the same address pairs) is about modifying the content of a 
single RTP session, it does not "mix different RTP sessions".
>
>  Even though RTP packets with different payload types could 
> potentially reuse the same SSRC value, SSRC values cannot be 
> independently assigned per m line with the current BUNDLE scheme since 
> RTCP packets can be identified only using SSRC values (payload type is 
> not a field in RTCP packets).  So the bundled m lines have to share a 
> single SSRC space, thus increasing the likelihood of SSRC collision
>
Yes. At 302 SSRCs in the same RTP session the chance of a collision is 
50%. Applications that don't handle SSRC collisions are broken.
>
> and preventing use of the same SSRC value across m lines and ports (as 
> some applications require).
>
These applications have a design mistake, and should be recommended 
against. While they are still in use, they force the use of multiple RTP 
sessions where it's otherwise superfluous. Luckily there are not that 
many of them.
>
>   To avoid these problems, translators implementing the current BUNDLE 
> will generally need to do SSRC mapping anyway, so BUNDLE cannot take 
> full advantage of the "randomness and flatness of the SSRC space".
>
RTP media translators in an RTP session where BUNDLE is used for setup 
need to set up their RTP sessions in such a way that either BUNDLE is 
used on all legs, or BUNDLE is used on no legs. This is because RTP 
media translators don't terminate RTP sessions.

Gateways that terminate RTP sessions have to remap SSRCs anyway. No news 
here.
>
> I have read your draft and should have referenced it in my paper.  I 
> agree that different media types should be able to share the same 
> transport connection.  But I also see a need to be able to apply 
> differential treatment of media types within the network.
>
Yes, some applications need that.
  In that case, the simplest way (allowing per-flow prioritization) is 
to use different RTP sessions on different transport addresses.
The next simplest way (using DiffServ) is to apply different DSCP 
markings on a per-packet basis. Both techniques are well established.

Breaking up the SSRC space and applying differential treatment based on 
that requires rewriting the traffic management components. That's new 
code that needs to be deployed. I don't see the need.
>
> You disagree with the need to separate packets associated with 
> different media lines for differential treatment in the network.
>
No, I don't disagree at all with that need, and have said so many times. 
I disagree that this is a need that is present *all the time*, and 
disagree that this need is so omnipresent that we need to shape our 
architectures around it.
>
>  Nevertheless, this issue has been raised in RFC 3550 and numerous 
> drafts since then as a legitimate issue in certain deployments.  While 
> I agree with you that there are significant use cases in which such 
> differential treatment is not necessary, there are others in which it 
> can be very beneficial.  It would be really unfortunate if there were 
> no way to support such use cases in rtcweb.
>
The point I was trying to make in rtp-sess-neutral is that the need for 
such differential treatment is orthogonal to the media types, and 
applications need to assign media streams to RTP sessions as the 
*applications*, not the *architecture*, think is adequate. That's really 
the focus of BUNDLE.

But really, this discussion belongs on AVTCORE.
>
> Richard
>
> ------------------------------------------------------------------------
>
> *From:*Harald Alvestrand [mailto:[email-masked]]
> *Sent:* Monday, June 04, 2012 1:43 PM
> *To:* Ejzak, Richard P (Richard)
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] draft on media multiplexing submitted to AVTCORE
>
> Richard,
> rectify, not promulgate, and additional complexity like what you 
> propose for perpetuating the use of "separated" sessions is not 
> helpful. See draft-alvestrand-rtp-sess-neutral for details.
>
> - When we have parts of the ecosystem that have code that is written 
> on the assumption that the SSRC space is a 32-bit flat space, I think 
> the partitioning of that space into subspaces as you propose is likely 
> to lead to "interesting" bugs. We should reinforce the randomness and 
> To: [email-masked] <mailto:[email-masked]>'
> From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
>
> [email-masked]  <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Jun 2012 09:11:53 +0200

Hi,

Harald,
While ideally we should be able to maintain the entire SSRC space for use by an RTP session, the current concept of BUNDLE breaks the model by mixing what are otherwise different RTP sessions together.  The scope of an RTP session is beyond just the transport connection on which bundling is occurring (see the RTP session topology diagrams in RFC 3550).
Yes, all parts of the RTP session need to agree on where the limits of the RTP session are. BUNDLE (the way it's currently written; Christer and I disagree on whether there is value in extending it to multiple sessions on the same address pairs) is about modifying the content of a single RTP session, it does not "mix different RTP sessions".

I am not sure whether I disagree with you. Yes, the BUNDLE mechanism can be extended (which I DO think is good) to be used also for multiple sessions, but I'll leave it to the RTP experts to discuss/decide what (if any) value there is in using multiple sessions :)

And, I even strongly agree with you that the RTP aspects of multiplexing should be discussed in AVTCORE :)

Regards,

Christer

 Even though RTP packets with different payload types could potentially reuse the same SSRC value, SSRC values cannot be independently assigned per m line with the current BUNDLE scheme since RTCP packets can be identified only using SSRC values (payload type is not a field in RTCP packets).  So the bundled m lines have to share a single SSRC space, thus increasing the likelihood of SSRC collision
Yes. At 302 SSRCs in the same RTP session the chance of a collision is 50%. Applications that don't handle SSRC collisions are broken.

and preventing use of the same SSRC value across m lines and ports (as some applications require).
These applications have a design mistake, and should be recommended against. While they are still in use, they force the use of multiple RTP sessions where it's otherwise superfluous. Luckily there are not that many of them.

  To avoid these problems, translators implementing the current BUNDLE will generally need to do SSRC mapping anyway, so BUNDLE cannot take full advantage of the "randomness and flatness of the SSRC space".
RTP media translators in an RTP session where BUNDLE is used for setup need to set up their RTP sessions in such a way that either BUNDLE is used on all legs, or BUNDLE is used on no legs. This is because RTP media translators don't terminate RTP sessions.

Gateways that terminate RTP sessions have to remap SSRCs anyway. No news here.

I have read your draft and should have referenced it in my paper.  I agree that different media types should be able to share the same transport connection.  But I also see a need to be able to apply differential treatment of media types within the network.
Yes, some applications need that.
 In that case, the simplest way (allowing per-flow prioritization) is to use different RTP sessions on different transport addresses.
The next simplest way (using DiffServ) is to apply different DSCP markings on a per-packet basis. Both techniques are well established.

Breaking up the SSRC space and applying differential treatment based on that requires rewriting the traffic management components. That's new code that needs to be deployed. I don't see the need.

You disagree with the need to separate packets associated with different media lines for differential treatment in the network.
No, I don't disagree at all with that need, and have said so many times. I disagree that this is a need that is present *all the time*, and disagree that this need is so omnipresent that we need to shape our architectures around it.

 Nevertheless, this issue has been raised in RFC 3550 and numerous drafts since then as a legitimate issue in certain deployments.  While I agree with you that there are significant use cases in which such differential treatment is not necessary, there are others in which it can be very beneficial.  It would be really unfortunate if there were no way to support such use cases in rtcweb.
The point I was trying to make in rtp-sess-neutral is that the need for such differential treatment is orthogonal to the media types, and applications need to assign media streams to RTP sessions as the *applications*, not the *architecture*, think is adequate. That's really the focus of BUNDLE.

Richard

Cc: [email-masked]<mailto:[email-masked]>

Richard,

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: [email-masked]<mailto:[email-masked]>'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

Richard

-----Original Message-----

Revision:   00

Number of pages: 9

Abstract:

The IETF Secretariat

rtcweb mailing list

---

From: Colin Perkins <[email-masked]>
Date: Tue, 5 Jun 2012 14:18:19 +0100

> On 06/04/2012 10:03 PM, Ejzak, Richard P (Richard) wrote:
...
> Yes. At 302 SSRCs in the same RTP session the chance of a collision is 50%. Applications that don't handle SSRC collisions are broken.

I agree that applications that don't handle SSRC collisions are broken, but RFC 3550 Section 8.1 gives a vastly lower probability of collision. Is there a mistake in the calculation in the RFC?

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Jun 2012 13:51:34 +0200

> I agree that applications that don't handle SSRC collisions are broken, but RFC 3550 Section 8.1 gives a vastly lower probability of collision. Is there a mistake in the calculation in the RFC?
Yes, the RFC is completely wrong.

Quote 1:

    If N is the number of sources and L the length of the
    identifier (here, 32 bits), the probability that two sources
    independently pick the same value can be approximated for large N
    [26] as 1 - exp(-N**2 / 2**(L+1)).  For N=1000, the probability is
    roughly 10**-4.

I don't have the book quoted, so I can't say where it's picked from. I 
suspect that this may be the probability that for any given two sources, 
they'll pick the same value, but I can't reverse engineer this.

Quote 2:

    Again, if N is the number of sources and L the length of the
    identifier, the probability of collision is N / 2**L.  For N=1000,
    the probability is roughly 2*10**-7.

This is the probability that a collision will occur when one adds SSRC 
number N+1 to the session that already contains N SSRCs that have been 
added without collision.

The exact formula for the chance that *any* collision happens will be 
the birthday paradox formula, which is easy to derive from the one above.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 06 Jun 2012 07:27:58 -0700

> the birthday paradox formula, which is easy to derive from the one above.

This is what I thought, too, but that just makes your 50% number more 
confusing. Plugging 302 and 4294967296 into 
http://jeff.aaron.ca/cgi-bin/birthday gives me 0.001%, not 50% (I got 
the same value when I worked it out myself). But one out of a thousand 
is still a not-insignificant number. The approximation in your Quote 1 
is actually pretty close, but _higher_ than the real value (by 0.3% of 
the real value, or 0.001058% (actual) vs. 0.001062% (approximate).

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 06 Jun 2012 07:38:55 -0700

> confusing. Plugging 302 and 4294967296 into

Also, if I'm working this out correctly, you cross the 50% threshold at 
6563 SSRCs instead of 302.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Jun 2012 22:04:16 +0200

On 06/06/2012 04:27 PM, Timothy B. Terriberry wrote:
> http://jeff.aaron.ca/cgi-bin/birthday gives me 0.001%, not 50% (I got the 
Argh. That's 4G. I was using 64K. Somehow I'd lost half the SSRC. 
Explains the difference.
My apologies.

I'll crawl under a rock now.

> same value when I worked it out myself). But one out of a thousand is 
> still a not-insignificant number. The approximation in your Quote 1 is 
> actually pretty close, but _higher_ than the real value (by 0.3% of