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

[Magnus Westerlund <[e-mail]>]

Hi Adam,

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

Den 2016-11-01 kl. 18:48, skrev Adam Roach:
> 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.

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.

>
> 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.

And my actual proposal for way forward was the following:

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

Cheers

Magnus


>
> /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, 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  [phone]
>> Färögatan 6                 | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------