Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage

[Harald Alvestrand <[e-mail]>]

On 04/15/2014 05:14 PM, Magnus Westerlund wrote:
> Hi,
>
> I have considered these comments and are okay with modifying the
> recommendation. I have modified the proposed text from Harald somewhat.
> My proposal is the following:
>
>
>     WebRTC implementations of RTP endpoints implemented according to this
>     memo are expected to support all the topologies described in
>     [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send
>     and receive unicast RTP packet streams to and from some peer device,
>     provided that peer can participate in performing congestion control
>     on the RTP packet streams.  The peer device could be another RTP
>     endpoint, or it could be an RTP middlebox that redistributes the RTP
>     packet streams to other RTP endpoints.  This limitation means that
>     some of the RTP middlebox-based topologies are not suitable for use
>     in the WebRTC environment.  Specifically:
>
>     o  Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used,
>        since they make the use of RTCP for congestion control and quality
>        of service reports problematic (see Section 3.8 of
>        [I-D.ietf-avtcore-rtp-topologies-update]).
>
>     o  The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology
>        SHOULD NOT be used because its safe use requires a point to
>        multipoint congestion control algorithm or RTP circuit breaker,
>        which has not yet been standardised.

Grammar warning: The above can be parsed as either

(multipoint congestion control algorithm) or (RTP circuit breaker)

or

multipoint ((congestion control algorithm) or (RTP circuit breaker))

Only the second parse will be a true statement once -circuit-breaker
(a normative dependency) is published. Perhaps this needs rephrasing?

>
>     The following topology may be used, however it has considerations
>     worth noting:
>
>     o  Content modifying MCUs with RTCP termination (Topo-RTCP-
>        terminating-MCU) MAY be used.  Note that in this RTP Topology, RTP
>        loop detection and identification of active senders is the
>        responsibility of the WebRTC application; since the clients are
>        isolated from each other at the RTP layer, RTP cannot assist with
>        these functions (see section 3.9 of
>        [I-D.ietf-avtcore-rtp-topologies-update]).
>
>
> Please provide feedback on this text!

This text looks reasonable to me.

>
> Please see further response to questions and comments inline below.
>
>
> On 2014-04-07 15:44, Harald Alvestrand wrote:
>> On 04/07/2014 01:15 PM, Magnus Westerlund wrote:
>>> On 2014-04-07 10:12, Harald Alvestrand wrote:
>>>> In my (strong) opinion: This recommendation is wrong.
>>>>
>>>> All central conferencing units that use individual RTP sessions with
>>>> clients fall into this category. This includes, I believe, every single
>>>> multiuser video conferencing system based on WebRTC in existence (and
>>>> there are many of them).
>>> Do they? The point of this topology is that it terminates the source
>>> identification and hides when it is performing any type of mixing or
>>> switching operation. You can perform this with a back to back RTP
>>> session style without breaking this property. Just by correctly linking
>>> information between the sessions.
>> Is there a definition for "correctly linking information"?
>> In particular, are you thinking of mappings that preserve SSRC?
>> Because that's not the ones I'm thinking of.
> The correctly linking information is mostly a question of preserving
> CNAMEs across the middlebox to ensure that an end-point can determine
> synchronization contexts, and origin if CSRC are used. As we add
> additional meta data about streams they may also needs to preserved
> depending on scope. Here it becomes a question of how one deals with
> APPID and MSID.
>
> Preserving SSRC is a choice, if one does it then loop detection works,
> if one doesn't preserve it it doesn't. Preserving it avoids having to
> remap any information that have global scope across the legs.
>
> It becomes a choice on what complexities one needs to handle, common
> uniqueness requirements versus remapping I think is the major trade-off.
>
>>>    Which means that the individual RTP
>>> session is from the identification part inseparable from an SFM or
>>> classic RTP mixer. Only the SSRC level loop detection gets impacted.
>>>
>>> I do understand that people have implemented it this way. Implementation
>>> are not necessarily equivalent to recommended practice.
>> But when there's one common practice, and no recommended practice, that
>> might be a gentle hint that there's a reason why people are doing it -
>> indeed, it might be worth making it a recommended practice.
> You are welcome to propose changes regarding this to the
> topologies-update document in AVTCORE WG.
>
>>>> I believe the recommendation should be:
>>>>
>>>> * Content modifying MCUs with RTCP termination
>>>> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP
>>>> loop detection and identification of active senders is the resposibility
>>>> of the application; since the clients are isolated from each other at
>>>> the RTP layer, RTP cannot assist with these functions.
>>>>
>>> If this topology was without issues, then one would simply remove the
>>> bullet, and let it fall under the general clause. However, it clearly
>>> needs that warning. Which results in this topology being both positively
>>> and negatively treated in regards to the other "you may encounter this
>>> topology".
>> It might need that warning - I'm not sure it's a real issue; loop
>> detection is only an issue when you have potential loops, and in a
>> single-mixer architecture, that potential is minimal (each endpoint
>> knows perfectly well the difference between what it's sourcing and what
>> it's receiving). Identification of active senders can be an
>> application-layer thing.
> Yes, I agree that in a basic conference application with only a single
> server instance this is unlikely to form a loop. If one starts doing
> more complex things, including multi-server conferences or
> PeerConnection Meshes things become more complex. The later we anyway
> have removed the RTP loop detection due to the CNAME being unique on
> PeerConnection level, but I do think that is the right trade-off from
> privacy point of view.
>
>> Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say.
> I do accept this, and are willing to change the recommendation.
>
> 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]
> ----------------------------------------------------------------------
>