Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

[Emil Ivov <[e-mail]>]

The scenario you outline may be one. I call that SSRC rewriting for Last N

Simulcast through SSRC rewriting (that you describe) is the one that
concerns us currently.



On Sat 2 Feb 2019 at 12:51, Bernard Aboba <[e-mail]> wrote:

> Emil said:
>
> "I want to second that as it is a particularly major problem: not allowing
> SSRC rewriting makes the entire framework unusable with SFU implementation
> I represent as well as every other SFU I am familiar with."
>
> [BA] Can you articulate why you consider SSRC rewriting essential to SFU
> operation?
>
> I can think of one scenario where SSRC rewriting does seem to be
> *required* -  Massive Online Courses (MOOCs). In these scenarios, there can
> be hundreds or even thousands of students, most of whom never speak during
> class, and teachers, who send media frequently.  MOOCs can be implemented
> via streaming media instead of RTP, but this complicates the interactive
> aspect.
>
> So there are implementations of MOOCs that use RTP, and I believe that
> SSRC rewriting is an important part of the design of these systems. For
> example, there are currently limitations in browsers as to the number of
> transceivers that can be active, so that providing a transceiver for each
> of the participants in the conference could conceivably cause the browser
> to run out of memory.
>
> This is circumvented by not exposing participants to the SSRCs of all of
> the users.  For example, the SFU may only allocate SSRCs for the professor
> and the "last N" students who have asked questions, so that a participant
> will only be aware of those SSRCs plus their own, instead of potentially
> needing to deal with the SSRCs of all the participants in the conference.
> This also has the effect of limiting the transceivers needed, most of which
> are in "recv-only" mode from the perspective of the course participants.
>
> When students wish to ask a question, permission is requested to access
> their devices (but not before).  Then once the student is speaking, their
> SSRC is translated, so that participants do not necessary see a new SSRC
> but only the SSRC of "the current speaking student".  Also, the SFU will
> typically consume the RTCP packets from students who are sending.
>
> On Sat, Feb 2, 2019 at 4:19 AM Emil Ivov <[e-mail]> wrote:
>
>> I want to second that as it is a particularly major problem: not allowing
>> SSRC rewriting makes the entire framework unusable with SFU implementation
>> I represent as well as every other SFU I am familiar with.
>>
>> I am also not sure that I agree with “SSRC rewriting could not be
>> allowed” is a conclusion that ever had any consensus in PERC, regardless of
>> what WG leadership is trying to make everyone believe.
>>
>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba <[e-mail]>
>> wrote:
>>
>>> Richard said:
>>>
>>> "Again, the answer is clear here, but the document should be clearer.
>>> The working group discussed SSRC rewriting several times, and concluded
>>> that SSRC rewriting could not be allowed in this system.  This decision is
>>> reflected, e.g., in the fact that the Double transform does not allow
>>> modification of SSRCs."
>>>
>>> [BA]  Not being able to rewrite SSRCs has some major implications with
>>> respect to requirements on PERC endpoints.  Typically today's MDD will
>>> switch between the simulcast streams provided by an endpoint, forwarding
>>> only a single stream to other participants, based on the bandwidth,
>>> resolution and framerates.  If rewriting of SSRCs is not possible, do PERC
>>> endpoints need to be able to receive simulcast? If PERC endpoints do need
>>> to be able to receive simulcast, what are the requirements for endpoints?
>>> For example, should endpoints expect the MDD to use RID header extensions
>>> to identify the incoming simulcast streams?
>>>
>>> Receiving of simulcast is tricky because the endpoint is receiving
>>> multiple streams with different sequence number spaces which may contain
>>> holes because of reordering or loss. This not only complicates the
>>> application of RTX, RED and FEC, but also the operation of the endpoint.
>>> As a result, as noted in the WEBRTC specification Section 5.4.1, support
>>> for reception of simulcast is optional. I am aware of two ORTC
>>> implementations that have attempted to support simulcast reception, neither
>>> of which is robust in scenarios with considerable loss and/or reordering.
>>> And neither implementation supports the RID header extension on received
>>> simulcast streams.
>>>
>>>
>>>
>>>
>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>> [e-mail]> wrote:
>>>
>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>
>>>> So I would propose we add something like the following to this
>>>> definition:
>>>>
>>>> "In the context of WebRTC, where control of a session is divided
>>>> between a JavaScript application and a browser, the browser acts as the
>>>> Trusted Endpoint for purposes of this framework (just as it acts as the
>>>> endpoint for DTLS-SRTP in one-to-one calls).
>>>>
>>>>
>>>> If we decide to adopt perc (big if) in webrtc, shouldn't this be
>>>> defined within the
>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17 doc ?
>>>>
>>>>
>>>>    Optimally, we would not rely on trust in any entities other than the
>>>>    browser.  However, this is unfortunately not possible if we wish to
>>>>    have a functional system.  Other network elements fall into two
>>>>    categories: those which can be authenticated by the browser and thus
>>>>    can be granted permissions to access sensitive resources, and those
>>>>    which cannot be authenticated and thus are untrusted.
>>>>
>>>>
>>>> WebRTC already IdP as trusted for identity purposes, so it should be up
>>>> to the RTCWEB group to decide what is a trusted endpoint and what is not in
>>>> webrtc. As Bernard is stating, we could decide that there are other key
>>>> management solutions trusted (even in JS or WASM), as for for example is
>>>> being done in EME:
>>>>
>>>>
>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption
>>>>
>>>> Best regards
>>>>
>>>> Sergio
>>>> _______________________________________________
>>>> Perc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>
>>> --
>> sent from my mobile
>>
> --
sent from my mobile