Subject: [MMUSIC] Simulcast: Inclusion of the same SCID in multiple Simulcast streams

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Nov 2016 10:46:10 +0100

WG,

During the reviews of the edits yesterday I did find one more issue that 
should be resolved to avoid interoperability issues. There is currently 
no text making it explicit if it is allowed to have the same simulcast 
format (and thus SCID) appear in multiple simulcast streams. I believe 
that unless we either explicit allow this or explicitly disallow it 
implementations will make different interpretations and thus we end up 
with interoperability issues.

So the reason Bo and I didn't conclude yesterday that this is a bad idea 
and we should just explicitly disallow it because it would simplify 
things are two reasons.

The first is that as we have attempted to create the best possibilities 
for future extensions, e.g. for multicast or at least spread one media 
source over multiple RTP sessions. Thus, forbidding things can cause 
issues for the ones defining such extensions, unless we see it necessary 
to ensure the base mechanism working.

Secondly, there are actually usage benefits for allowing a format to be 
included in multiple simulcast streams. A not unusual way to consider 
simulcast streams is that they fulfill a purpose in the application. For 
example one simulcast is the video suitable to present the current 
speaker in a better fidelity version with higher resolution. One may 
also have a simulcast stream suitable for the recent speakers that is an 
intermediate format between high resolution and low resolution 
thumbnails. In such a case the simulcast stream for the high resolution 
could include a least preferred simulcast format (SCID=Y) of a rather 
low resolution version (for being the high resolution) as the last 
fallback for this streams purpose. At the same time the intermediate 
simulcast stream could include the same format SCID=Y as suitable format 
for this medium resolution usage, possible with a much higher preference 
as it would provide good quality for this streams purpose. So by 
including the same format in two streams, in situation where the media 
sender becomes resource restrained, for example in bandwidth, the media 
source sender could make the decision that the best way of providing 
both the high and intermediate simulcast streams are to select to send a 
single RTP stream according to SCID=Y that matches both.

If one would not allow an SCID to be in multiple simulcast streams, then 
the likely result in the above case is that one have to turn of the high 
resolution simulcast stream due to insufficient resources. This may or 
may not mean that the application logic chooses to use the intermediate 
stream as stand in for the high, given that the stream fits the 
restriction of any of the high resolution simulcast stream's formats.

So, this example is not particular convincing in regards to why one 
should allow this, as the application logic and with some care when 
negotiating the simulcast formats for the different streams still can 
allow a simulcast using middlebox to utilize the simulcast stream as 
stand in for another simulcast stream if that one is not available.

So, I currently don't have any better example of why one would allow it, 
but I think it is important that the WG gets to think about this. So 
please consider if you have usage that would benefit from allowing 
multiple simulcast streams to include the same format (with the same 
SCID)? If no good usage arises then I suggest we explicitly disallow it. 
Please provide your feedback by the end of the IETF meeting (18th of 
November).

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Tue, 1 Nov 2016 12:48:04 -0500

Unless there are really strong and compelling reasons for making this 
change, I am strongly opposed to it. Draft-ietf-avtext-rid is already in 
the RFC editor queue, and it scopes RtpStreamIds (which is the 
underlying RTP representation of a SCID) to be unique within a single 
RTP session; and, if BUNDLE is being used, to be unique within a single MID.

To accommodate the change you describe, we'd have to pull 
draft-ietf-avtext-rid out of the RFC editor queue and change scoping 
rules altogether.

To be clear, the *current* property is that SCIDs can't be shared 
between multiple simulcast streams, although this is only expressed 
through the use of RtpStreamId as the underlying RTP construct. Even 
though this is unambiguous, it would probably be good to re-state that 
constraint in the simulcast document.

/a

On 11/1/16 04:46, Magnus Westerlund wrote:
> WG,
>
> During the reviews of the edits yesterday I did find one more issue 
> that should be resolved to avoid interoperability issues. There is 
> currently no text making it explicit if it is allowed to have the same 
> simulcast format (and thus SCID) appear in multiple simulcast streams. 
> I believe that unless we either explicit allow this or explicitly 
> disallow it implementations will make different interpretations and 
> thus we end up with interoperability issues.
>
> So the reason Bo and I didn't conclude yesterday that this is a bad 
> idea and we should just explicitly disallow it because it would 
> simplify things are two reasons.
>
> The first is that as we have attempted to create the best 
> possibilities for future extensions, e.g. for multicast or at least 
> spread one media source over multiple RTP sessions. Thus, forbidding 
> things can cause issues for the ones defining such extensions, unless 
> we see it necessary to ensure the base mechanism working.
>
> Secondly, there are actually usage benefits for allowing a format to 
> be included in multiple simulcast streams. A not unusual way to 
> consider simulcast streams is that they fulfill a purpose in the 
> application. For example one simulcast is the video suitable to 
> present the current speaker in a better fidelity version with higher 
> resolution. One may also have a simulcast stream suitable for the 
> recent speakers that is an intermediate format between high resolution 
> and low resolution thumbnails. In such a case the simulcast stream for 
> the high resolution could include a least preferred simulcast format 
> (SCID=Y) of a rather low resolution version (for being the high 
> resolution) as the last fallback for this streams purpose. At the same 
> time the intermediate simulcast stream could include the same format 
> SCID=Y as suitable format for this medium resolution usage, possible 
> with a much higher preference as it would provide good quality for 
> this streams purpose. So by including the same format in two streams, 
> in situation where the media sender becomes resource restrained, for 
> example in bandwidth, the media source sender could make the decision 
> that the best way of providing both the high and intermediate 
> simulcast streams are to select to send a single RTP stream according 
> to SCID=Y that matches both.
>
> If one would not allow an SCID to be in multiple simulcast streams, 
> then the likely result in the above case is that one have to turn of 
> the high resolution simulcast stream due to insufficient resources. 
> This may or may not mean that the application logic chooses to use the 
> intermediate stream as stand in for the high, given that the stream 
> fits the restriction of any of the high resolution simulcast stream's 
> formats.
>
> So, I currently don't have any better example of why one would allow 
> it, but I think it is important that the WG gets to think about this. 
> So please consider if you have usage that would benefit from allowing 
> SCID)? If no good usage arises then I suggest we explicitly disallow 
> it. Please provide your feedback by the end of the IETF meeting (18th 
> of November).
>
> Cheers
>
> Magnus Westerlund
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Nov 2016 10:04:04 +0100

Hi Adam,

I get the impression there is a bit of missunderstanding here.

> RTP session; and, if BUNDLE is being used, to be unique within a single

I am not proposing to change the RID limitation. I might not have been 
clear on that in cases where one SCID would fulfill two simulcast 
streams there would be only one RTP stream, not two as it usually would 
if there was no overlap defined.

> constraint in the simulcast document.

And my actual proposal for way forward was the following:

"If no good usage arises then I suggest we explicitly disallow it."

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Wed, 2 Nov 2016 13:34:27 +0200

Hi Magnus,
I would like to verify that I understand this correctly.

The case is about having a media source that sends simulcast streams in two
RTP sessions represented in SDP by two m-lines. The first one will have, for
example, HD resolution and CIF while the second will have SD and same CIF as
the first one. You suggest to not allow having the CIF in both RTP sessions
but still allow having, for example, one with HD and VGA and a second with
SD and CIF?

I see value when using multicast with simulcast to have one multicast group
with HD and a second multicast with SD and maybe a third multicast with CIF
from the same source (example case is streaming live events (sports, ...)
using simulcast and multicast for distribution)

Roni

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: Tuesday, November 01, 2016 11:46 AM
> To: mmusic (E-mail); [email-masked]
> Subject: [MMUSIC] Simulcast: Inclusion of the same SCID in multiple
> Simulcast streams
> 
> WG,
> 
> should be resolved to avoid interoperability issues. There is currently no
text
> making it explicit if it is allowed to have the same simulcast format (and
thus
> SCID) appear in multiple simulcast streams. I believe that unless we
either
> explicit allow this or explicitly disallow it implementations will make
different
> interpretations and thus we end up with interoperability issues.
> 
and
> we should just explicitly disallow it because it would simplify things are
two
> reasons.
for
> future extensions, e.g. for multicast or at least spread one media source
over
> multiple RTP sessions. Thus, forbidding things can cause issues for the
ones
> defining such extensions, unless we see it necessary to ensure the base
> mechanism working.
> 
example
> one simulcast is the video suitable to present the current speaker in a
better
> fidelity version with higher resolution. One may also have a simulcast
stream
> suitable for the recent speakers that is an intermediate format between
high
> resolution and low resolution thumbnails. In such a case the simulcast
stream
> for the high resolution could include a least preferred simulcast format
resolution) as
> the last fallback for this streams purpose. At the same time the
intermediate
> for this medium resolution usage, possible with a much higher preference
as
> it would provide good quality for this streams purpose. So by including
the
> same format in two streams, in situation where the media sender becomes
> resource restrained, for example in bandwidth, the media source sender
> could make the decision that the best way of providing both the high and
> intermediate simulcast streams are to select to send a single RTP stream
> according to SCID=Y that matches both.
> 
the
> likely result in the above case is that one have to turn of the high
resolution
> simulcast stream due to insufficient resources. This may or may not mean
> that the application logic chooses to use the intermediate stream as stand
in
> for the high, given that the stream fits the restriction of any of the
high
> resolution simulcast stream's formats.
> 
> So, this example is not particular convincing in regards to why one should
> allow this, as the application logic and with some care when negotiating
the
> simulcast formats for the different streams still can allow a simulcast
using
> middlebox to utilize the simulcast stream as stand in for another
simulcast
> stream if that one is not available.
> 
but I
> think it is important that the WG gets to think about this. So please
consider
> if you have usage that would benefit from allowing multiple simulcast
> streams to include the same format (with the same SCID)? If no good usage
> arises then I suggest we explicitly disallow it.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 2 Nov 2016 13:49:12 +0200

Hi Magnus,
Looking more at your question and since I do not see so much usage of
multicast in multipoint conferencing applications, this looks OK. Section
6.4 almost addresses my concern about usage of simulcast with multicast in
SDP for streaming like applications. Will send a separate email
Roni

> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, November 02, 2016 1:34 PM
> To: 'Magnus Westerlund'; 'mmusic (E-mail)'; 'draft-ietf-mmusic-sdp-
> [email-masked]'
> Subject: RE: [MMUSIC] Simulcast: Inclusion of the same SCID in multiple
> Simulcast streams
> 
> Hi Magnus,
> example, HD resolution and CIF while the second will have SD and same CIF
> as the first one. You suggest to not allow having the CIF in both RTP
sessions
> > simulcast format (and thus
> > either explicit allow this or explicitly disallow it implementations
> > will make different interpretations and thus we end up with
interoperability
> issues.
> > simulcast streams are to select to send a single RTP stream according to
> SCID=Y that matches both.
> >
formats.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Nov 2016 13:01:37 +0100

> but still allow having, for example, one with HD and VGA and a second with

It is one RTP session, one SDP media description. But for that one you 
are declaring something like a=simulcast:send 1,2,3;3,4,5 where SCID=3 
could be a CIF case you exemplify with.

And in case the sender selects to provide SCID=3, then only one RTP 
stream would actually be sent.

> using simulcast and multicast for distribution)

So, this is not all addressing the case when you have multiple RTP 
session, for example due to need to have different multicast groups for 
the different simulcast streams.

To be clear, I am actually not advocating for allowing the same SCID to 
be used in multiple simulcast streams. I believe there are better 
alternatives to handle the situations it could address, based on 
application logic. But, I didn't want to take a decision myself to 
forbid it without some mailing list discussion. And there might be 
usages which I am not considering.

Cheers

Magnus Westerlund

---

From: Adam Roach <[email-masked]>
Date: Wed, 2 Nov 2016 15:14:36 -0500

> I get the impression there is a bit of missunderstanding here.

Indeed there was. Your later example ("a=simulcast:send 1,2,3;3,4,5 
where SCID=3 could be a CIF case you exemplify with") clarified your 
proposal nicely.

I have no opinion on the utility of allowing or disallowing such a 
formulation, although I agree that the document should be explicit 
regarding whether doing so is valid.

/a