Subject: [AVTCORE] Call for consensus on multiplexing multipe media streams.

From: Roni even <[email-masked]>
Date: Mon, 14 Nov 2011 08:56:38 +0000

Hi

At the AVTcore session we had two presentations. One from Magnus proposing the multiplexing of multiple RTP sessions over a single transport flow and the second from Jonathan Lennox proposing multiplexing multiple media types in a single RTP session.

Magnus asked in the beginning of his presentation if the WG believe that the problem of providing multiple RTP sessions over a single transport flow should be solved. The response from the room was that it was already discussed in IETF 81 and there was interest in doing this work.

In IETF81 there was an interest in doing both options. During the session today we did not have time to ask for consensus.

So the WG chairs are asking which direction to take

The options we have are:

1. Go forward with both solutions.

2. Only define multiplexing of multiple RTP sessions in a single transport flow.

3. Only define multiplexing of multiple media types in a single RTP session.

4. Not enough information in order to decide, more discussion is needed.

There were about 20 people in the AVTcore session who raised there hands when asked if they have opinion

Thanks

Roni Even

AVTcore co-chair

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Nov 2011 17:45:11 +0800

> 4. Not enough information in order to decide, more discussion is needed.

My personally view:
I don't think 3 is a viable option based on the the consensus that
appears to exist that the multiple RTP session solution should exist.

My preference is for 2 as I believe it can solve all the necessary
cases. But I will live with a consensus decision becoming 1 and shut up
and try to ensure both solutions are as quickly progressed as they can
individually.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Nov 2011 18:33:47 +0800

On 11/14/2011 04:56 PM, Roni even wrote:
>
> Hi
>
> At the AVTcore session we had two presentations. One from Magnus
> proposing the multiplexing of multiple RTP sessions over a single
> transport flow and the second from Jonathan Lennox proposing
> multiplexing multiple media types in a single RTP session.
>
> Magnus asked in the beginning of his presentation if the WG believe
> that the problem of providing multiple RTP sessions over a single
> transport flow should be solved. The response from the room was that
> it was already discussed in IETF 81 and there was interest in doing
> this work.
>
> In IETF81 there was an interest in doing both options. During the
> session today we did not have time to ask for consensus.
>

I don't see these 4 as a set from which it is reasonable to pick one and
only one choice...

My preferred option is 1.
I think that 3 is a viable option for my scenarios.
I am strongly opposed to 2.

(I am also strongly opposed to using the term "multiplexing" for the
activity described in 3. I would prefer
"sending", which I think is more descriptive and more clearly different
from the multiplexing option.)

I think this is not a surprise to anyone who was present in the meeting.

Harald

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 14 Nov 2011 05:57:54 -0800

In today's session, Magnus and Colin presented a set of requirements for
(2). During the session, it was argued by several people that the set of
requirements could and should be relaxed in their use cases. For such
use cases, I think (3) is the best solution and (2) is not necessary.
If you really need to multiplex multiple media types over a single port
for use cases matching the requirements listed by Magnus and Colin, then
I trust they are correct and really do need (2) as well. 
However, if the only reason such uses cases exist is to build something
that does interworking between something that uses (3) and something
that requires (2), one would likely do so by demultiplexing the multiple
media types into multiple non-multiplexed RTP sessions, as we do today,
so I do not think (2) is necessary.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni even
> Sent: Monday, November 14, 2011 4:57 PM
> To: [email-masked]
> Subject: [AVTCORE] Call for consensus on multiplexing multipe media
streams.
> At the AVTcore session we had two presentations. One from Magnus
proposing the multiplexing of
> multiple RTP sessions over a single transport flow and the second from
Jonathan Lennox proposing
> Magnus asked in the beginning of his presentation if the WG believe
that the problem of providing
> multiple RTP sessions over a single transport flow should be solved.
The response from the room was
> that it was already discussed in IETF 81 and there was interest in
doing this work.
> In IETF81 there was an interest in doing both options. During the
session today we did not have time
> to ask for consensus.
> There were about 20 people in the AVTcore session who raised there
hands when asked if they have
> opinion

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Nov 2011 23:56:33 +0800

> I trust they are correct and really do need (2) as well.

I think when those requirements doesn't apply do need to be written up
in the form of an applicability statement for when (3) do works.

> so I do not think (2) is necessary.

No, that is not the only reason. We do see a need for multiple RTP
session over the single transport. Not simply to interwork 3 with legacy.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Nov 2011 01:11:11 +0000

Harald,
Can you explain why you're strongly opposed to 2?  It would help me make a more informed decision myself.

I know the advantages of #2, some of which haven't been articulated yet I think... but what I don't know is what its disadvantages are that would make us choose #3 instead.

-hadriel

On Nov 14, 2011, at 5:33 AM, Harald Alvestrand wrote:

Hi

The options we have are:

I don't see these 4 as a set from which it is reasonable to pick one and only one choice...

(I am also strongly opposed to using the term "multiplexing" for the activity described in 3. I would prefer
"sending", which I think is more descriptive and more clearly different from the multiplexing option.)

                    Harald

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Nov 2011 09:31:13 +0800

Trying to make the chairs' job of tallying easier by changing the 
subject when we fork into discussion rather than the call for consensus 
itself....

On 11/15/2011 09:11 AM, Hadriel Kaplan wrote:
> I know the advantages of #2, some of which haven't been articulated 
> yet I think... but what I don't know is what its disadvantages are 
> that would make us choose #3 instead.
#2 implies that we would not have a standard way to negotiate sending 
media with different top-level content types (such as audio and video, 
or audio and text) in the same RTP session.

This is today a limitation of SDP, not RTP, although some language in 
RFC 3550 (section 2.2) indicates that this was an intentional limitation 
when designing the SDP/RTP protocol suite.

I believe this decision was a bad decision, and that the issue of how 
many sessions to use, and what to pass on each session, should be left 
strictly to the application.
This requires an extension to SDP; in RTP, all that I believe is 
required is that we stop stating the assumption; no wire protocol 
changes should be needed.

                          Harald

---

From: Stephen Casner <[email-masked]>
Date: Mon, 14 Nov 2011 17:37:23 -0800 (PST)

On Tue, 15 Nov 2011, Harald Alvestrand wrote:

> Trying to make the chairs' job of tallying easier by changing the subject when
> we fork into discussion rather than the call for consensus itself....
>
> > I know the advantages of #2, some of which haven't been articulated yet I
> > think... but what I don't know is what its disadvantages are that would make
> > us choose #3 instead.
> #2 implies that we would not have a standard way to negotiate sending media
> with different top-level content types (such as audio and video, or audio and
> text) in the same RTP session.
>
> This is today a limitation of SDP, not RTP, although some language in RFC 3550
> (section 2.2) indicates that this was an intentional limitation when designing
> the SDP/RTP protocol suite.

See also RFC 3550 section 5.2 for a list of reasons why not to do this.

                                                        -- Steve

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Nov 2011 09:52:31 +0800

> See also RFC 3550 section 5.2 for a list of reasons why not to do this.
We've been over this several times. Didn't we do it on this list too?

1, 2 and 3 are only relevant to PT-based multiplex, which I think nobody 
argues for.
The ones that are left 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.

4 is only relevant for applications that need to support blind mixing: 
where streams are mixed without knowing what their content is. A mixer 
that can tell the difference between an OPUS stream and a G.722 stream 
is also able to tell the difference between VP8 and G.722.

5 is a matter that I think should be left for the application developer 
to decide whether he cares about it or not, and how it balances against 
the real cost of supporting sessions over multiple network paths; I 
believe that making this decision at the RTP layer, which is, after all, 
a tool for applications, not an application in itself, is inappropriate.

(note: several of the points in bullet 5 also are functions that are 
lost in a session-multiplexing scenario, so they are irrelevant to the 
decision that is in front of us now.)

                             Harald

---

From: Colin Perkins <[email-masked]>
Date: Tue, 15 Nov 2011 10:11:16 +0800

> 4. Not enough information in order to decide, more discussion is needed.

I support option (2), and think option (3) is problematic for the reasons described in draft-perkins-rtcweb-rtp-usage-02. 

I can live with option (1), provided the limitations of both approaches are clearly specified. 

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

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 15 Nov 2011 18:33:01 -0800

I think more discussion  is needed- option 4. 

I don’t see any really clear analysis of the pros and cons of 2 and 3 - despite what is in Magnus’ draft.

Thanks,

Allyn

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni even
Sent: Monday, November 14, 2011 12:57 AM
To: [email-masked]
Subject: [AVTCORE] Call for consensus on multiplexing multipe media streams.

Hi

 

The options we have are:

 

Thanks

Roni Even

AVTcore co-chair

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 06:59:04 +0000

I think option 4 is right: there has not been enough discussion to decide.  Unfortunately there was insufficient time in the WG meeting to truly cover/discuss the one slide which actually had a comparison table. 

I am slightly against Option 1, because choosing both is rarely a good thing for interoperability unless the market would end up only choosing the same one in the end anyway for some reason, or unless there are actual pro's/con's which make picking one and only one impractical.  

-hadriel

On Nov 14, 2011, at 3:56 AM, Roni even wrote:

> [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 14:15:12 +0000

On Nov 14, 2011, at 8:31 PM, Harald Alvestrand wrote:

> Trying to make the chairs' job of tallying easier by changing the subject when we fork into discussion rather than the call for consensus itself....
> 
> #2 implies that we would not have a standard way to negotiate sending media with different top-level content types (such as audio and video, or audio and text) in the same RTP session.
> 
> This is today a limitation of SDP, not RTP, although some language in RFC 3550 (section 2.2) indicates that this was an intentional limitation when designing the SDP/RTP protocol suite.
> 
> I believe this decision was a bad decision, and that the issue of how many sessions to use, and what to pass on each session, should be left strictly to the application.
> This requires an extension to SDP; in RTP, all that I believe is required is that we stop stating the assumption; no wire protocol changes should be needed.

But if I understand what you're saying above, you're basically saying #2 is bad because it doesn't enable you to do #3.  No?

But that doesn't answer the question - what's actually bad with sending different media types in separate RTP sessions in the same 5-tuple, using a mux/demux header?  Or conversely, what's better about being able to send them in the same RTP session?

I can see actual advantages for keeping them separate RTP sessions and using a shim header approach - what I don't see are negatives to doing so, nor positives for using a single RTP session.

-hadriel

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Nov 2011 15:08:19 +0100

Just a note - I count 8 people as having stated an opinion so far.

That's fewer than the number of people who had an opinion in AVTEXT.
Of course, people may have been convinced by the strong arguments of
those who said we can't decide yet.... in which case, it makes sense to
speak up for alternative 4.

On 11/14/2011 09:56 AM, Roni even wrote:
> hands when asked if they have opinion
>
> Thanks
>
> Roni Even
>
> AVTcore co-chair
>
> 　
>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 22 Nov 2011 10:00:45 -0600

I think there is a 5th option:

5) Either 2) or 3) as I think some folks would like a single solution,
but it doesn't matter which of the two is selected.

Regards,
Mary.

2011/11/14 Roni even <[email-masked]>:
> Hi
>
> At the AVTcore session we had two presentations. One from Magnus proposing
> the multiplexing of multiple RTP sessions over a single transport flow and
> the second from Jonathan Lennox proposing multiplexing multiple media types
> in a single RTP session.
>
>
>
> Magnus asked in the beginning of his presentation if the WG believe that the
> problem of providing multiple RTP sessions over a single transport flow
> should be solved. The response from the room was that it was already
> discussed in IETF 81 and there was interest in doing this work.
>
> In IETF81 there was an interest in doing both options. During the session
> today we did not have time to ask for consensus.
>
>
>
>
>