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

[Magnus Westerlund <[e-mail]>]

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.

   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!

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