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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Apr 2014 11:24:32 +0200

WG,
(As Author)

Colin and I have been working on resolving terminology usage and in
general giving the draft a polish over before the WG last call. One
section that has gotten quite some attention from us is the below one.
The changes are significantly from an editorial stand point. However,
the intended content has not been intended to be changed, although
clarified and better motivated. So please review it, we intended to
include this in the upcoming draft update. Feedback appreciated.

5.1.  Conferencing Extensions and Topologies

   RTP is a protocol that inherently supports group communication.
   Groups can be implemented by having each endpoint sending its RTP
   packet streams to an RTP middlebox that redistributes the traffic, by
   using a mesh of unicast RTP packet streams between endpoints, or by
   using an IP multicast group to distribute the RTP packet streams.
   These topologies can be implemented in a number of ways as discussed
   in [I-D.ietf-avtcore-rtp-topologies-update].

   While the use of IP multicast groups is popular in IPTV systems, the
   topologies based on RTP middleboxes are dominant in interactive video
   conferencing environments.  Topologies based on a mesh of unicast
   transport-layer flows to create a common RTP session have not seen
   widespread deployment.  Accordingly, WebRTC implementations are not
   expected to support topologies based on IP multicast groups.  WebRTC
   implementations are also not expected to support mesh-based
   topologies, such as a point-to-multipoint mesh configured as a single
   RTP session (Topo-Mesh in the terminology of
   [I-D.ietf-avtcore-rtp-topologies-update]).  However, a point-to-
   multipoint mesh constructed using several RTP sessions, in the WebRTC
   context using independent RTCPeerConnections can be expected to be
   utilised by WebRTC applications.

   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 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.6.2 of
      [I-D.ietf-avtcore-rtp-topologies-update]).

   o  Content modifying MCUs with RTCP termination (Topo-RTCP-
      terminating-MCU) SHOULD NOT be used since they break RTP loop
      detection, and prevent receivers from identifying active senders
      (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 RTP extensions described in Section 5.1.1 to Section 5.1.6 are
   designed to be used with centralised conferencing, where an RTP
   middlebox (e.g., a conference bridge) receives a participant's RTP
   packet streams and distributes them to the other participants.  These
   extensions are not necessary for interoperability; an RTP end-point
   that does not implement these extensions will work correctly, but
   might offer poor performance.  Support for the listed extensions will
   greatly improve the quality of experience and, to provide a
   reasonable baseline quality, some of these extensions are mandatory
   to be supported by WebRTC end-points.

   The RTCP conferencing extensions are defined in Extended RTP Profile
   for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
   AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio-
   Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully
   usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124].

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: Christian Groves <[email-masked]>
Date: Mon, 07 Apr 2014 12:42:17 +1000

Hello Magnus,

Please see my comments marked CNG below.

Regards, Christian

>        [I-D.ietf-avtcore-rtp-topologies-update]).
[CNG] Is 3.6.2 the right reference? clause 3.8 talks about 
Topo-Video-switch-MCU and the reports problem.
>        (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]).
[CNG] Is 3.8 the right reference? clause 3.9 talks about loop detection 
for Topo-RTCP-
       terminating-MCU.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Apr 2014 10:12:14 +0200

Thanks for the update!

It does seem reasonably clear now - clear enough that I found one point 
that I violently disagree with (if I'm interpreting it correctly). See 
below.

I don't have any negative comments on the rest of the section.

>        (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]).

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

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Apr 2014 13:15:14 +0200

> multiuser video conferencing system based on WebRTC in existence (and

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

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

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Apr 2014 13:16:35 +0200

Thanks Christian,

You are correct, these section references points to the wrong sections,
will address.

/Magnus

-- 

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Apr 2014 15:44:27 +0200

On 04/07/2014 01:15 PM, Magnus Westerlund wrote:
> 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.

>   Which means that the individual RTP

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.
> and negatively treated in regards to the other "you may encounter this

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.

Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 8 Apr 2014 18:04:50 +0300

Hi,
Inline
Roni

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 07 April, 2014 2:15 PM
> To: Harald Alvestrand; [email-masked]
> Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> ietf-rtcweb-rtp-usage
> > It does seem reasonably clear now - clear enough that I found one
> > point that I violently disagree with (if I'm interpreting it
> > correctly). See below.
> >
> > 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).
> 
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. 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.
are
> not necessarily equivalent to recommended practice.
> 
[Roni Even] In this topology the source identification is done by the
application layer and not the RTP layer (using for example conference event
package or just the UI). So I think that "MAY" is strong enough and not
"SHOULD NOT". I agree with Harald that it is widely used.

> > (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.
> >
> 
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".
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 8 Apr 2014 18:13:19 +0300

Hi,
Comment on video switching in-line
Roni

> Sent: 04 April, 2014 12:25 PM
> To: [email-masked]
> Cc: Colin Perkins
> Subject: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> Colin and I have been working on resolving terminology usage and in
general
> giving the draft a polish over before the WG last call. One section that
has
> gotten quite some attention from us is the below one.
> The changes are significantly from an editorial stand point. However, the
> intended content has not been intended to be changed, although clarified
and
> better motivated. So please review it, we intended to include this in the
> upcoming draft update. Feedback appreciated.
> 
[Roni Even] I think that SHOULD NOT is too strong here better use MAY be
used, this is a simple common mode of centralized video conferencing being
used. If you are talking about the RTP layer the MCU gets all the RTCP
reports. The problem of loop detection may occur when cascading MCUs and the
avtcore topology should point it out. I do not see it as a major problem
since the video switching is managed by the application layer who should
prevent such situations.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Apr 2014 14:22:11 +0200

> since the video switching is managed by the application layer who should

Roni,

I think you need to go read the definition of the topology in the draft.
As defined in the topologies update draft, that behaviour is not
acceptable towards an WebRTC end-point that uses RTCP for congestion
control.

I quote the most important parts (Section 3.8) from -01:

  "A video switching MCU forwards to a participant a single media
   stream, selected from the available streams.  The criteria for
   selection are often based on voice activity in the audio-visual
   conference, but other conference management mechanisms (like
   presentation mode or explicit floor control) are known to exist as
   well.

   The video switching MCU may also perform media translation to modify
   the content in bit-rate, encoding, or resolution.  However, it still
   may indicate the original sender of the content through the SSRC.  In
   this case, the values of the CC and CSRC fields are retained.

   If not terminating RTP, the RTCP Sender Reports are forwarded for the
   currently selected sender.  All RTCP Receiver Reports are freely
   forwarded between the participants.  In addition, the MCU may also
   originate RTCP control traffic in order to control the session and/or
   report on status from its viewpoint.

   The video switching MCU has most of the attributes of a Translator.
   However, its stream selection is a mixing behavior.  This behavior
   has some RTP and RTCP issues associated with it.  The suppression of
   all but one media stream results in most participants seeing only a
   subset of the sent media streams at any given time, often a single
   stream per conference.  Therefore, RTCP Receiver Reports only report
   on these streams.  Consequently, the media senders that are not
   currently forwarded receive a view of the session that indicates
   their media streams disappear somewhere en route.  This makes the use
   of RTCP for congestion control, or any type of quality reporting,
   very problematic."

I think the behaviour you are interested in falls under the RTP mixer
behaviour either the Mixing (Section 3.6.1) or the Switching (Section
3.6.2) where RTCP is properly handled.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Apr 2014 17:14:12 +0200

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

   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.

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

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

> it's receiving). Identification of active senders can be an

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Apr 2014 23:57:10 +0200

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

> Please provide feedback on this text!

This text looks reasonable to me.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Apr 2014 14:26:20 +0200

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

It is the later that was intended. Because the topology requires
congestion control for multi endpoint.

Will reword.

Thanks

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Sun, 20 Apr 2014 18:38:46 +0300

Hi Magnus,
I am OK with the text.
Do you think that for Multiparty we should state that a mixed conference
(WebRTC and non WebRTC participants) is possible and should also support
these rules.
 
Roni 

> Sent: 15 April, 2014 6:14 PM
draft-
> >> session style without breaking this property. Just by correctly
> >> linking information between the sessions.
> >
CNAMEs
> across the middlebox to ensure that an end-point can determine
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.
> 
> >>   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.
> 
> >>
> >>> resposibility of the application; since the clients are isolated
> >>> from each other at the RTP layer, RTP cannot assist with these
functions.
> >> needs that warning. Which results in this topology being both
> >> positively and negatively treated in regards to the other "you may
> >> encounter this topology".
> >
> > 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.
> 
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.
> 
> >

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Apr 2014 21:56:40 +0000

On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <[email-masked]> wrote:

> This limitation means that

I think this is deserving of some WG discussion as people may not be up to speed of what this is allowing or not allowing. My understanding was several companies at the last WebRTC Expo conference were demonstrating system that used this type of MCU. 

If SRTP were more flexible and there was a way to a mixer work without giving it the keys to the decrypt the media, I think people would be keener on mixers but right it seems like the pro / cons invovle a trade off between significant security functionally loss and possible loss of some RTCP data which many systems totally ignore.  Anyway, not taking any opinion other than this seems like a significant enough change to have some discussion on it.