Re: [rtcweb] Review of draft-perkins-rtcweb-usage-03 (Re: Fwd: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt)

[Colin Perkins <[e-mail]>]

On 31 Aug 2011, at 08:41, Harald Alvestrand wrote:
> On 08/30/11 18:22, Colin Perkins wrote:
>> On 29 Aug 2011, at 14:33, Harald Alvestrand wrote:
>>> Colin, I really like this version!
>>> 
>>> There might want to be a placeholder about multiplexing, saying "we will return to this issue after more discussion". Otherwise, it seems to me we're setting up the expectation that this will be handled entirely in some other document - I think the end product of the WG needs to discuss it, and it seems logical that some aspect of it should go here.
>> Yes, I'll add this.
>> 
>>> Some detailed comments:
>>> 
>>> - In Figure 2, section 1.1, I think you're making the assumption that multi-unicast topologies will use a single shared RTP session (SSRC number space) for all the links. This is not obvious; it's possible to build this topology on point-to-point RTP sessions too.
>> It's possible, but not necessarily desirable. Building this using a single RTP session (with a shared SSRC space) makes debugging a lot easier, since you can do third-party debugging (e.g., you can see from the RTCP that Alice can hear Bob talking, but you can't, so you know there's a problem somewhere, and can alert the user). It also enables various other features, such as third-party retransmissions.
> It also means that all the sessions have to have a single bandwidth number, since otherwise you can't get a consistent RTCP send rate, for instance.

True (although this has already been somewhat broken by the decision to multiplex audio and video in the same RTP session).

> Speaking for some implementors of the WEBRTC API, it's also clear that there's a significant cost to implementing the multiway RTP session concept - both in code complexity and API complexity. I think this warrants more discussion, where all 3 outcomes should be on the table:
> 
> - We recommend doing multi-unicast with a shared RTP session only
> - We recommend supporting both shared and split RTP sessions for multi-unicast
> - We recommend doing multi-unicast with split RTP sessions only
> 
> We should probably do this in a new thread.

Indeed; I'd be interested to know what complexity you're seeing. I would have expected the shared RTP session model to decrease complexity, since the RTP layer can be oblivious to the detail of the underlying transport connections, and wouldn't have to worry about tracking SSRC and payload type mapping separately for each session.

...
>>> - In section 6, I would recommend removing the point about scenarios with mixers using point-to-point RTP sessions are "not well utilizing the mechanisms of RTP" - I think people's engineering tradeoffs should be respected.
>>> I'm fine with leaving in the comment about protocol violations (although I'd like to be more specific about what they are - protocols shouldn't be violated; if people "have" to do that, there's something wrong with the protocol).
>> The referenced sections of RFC 5117 list specific technical problems with these approaches. I agree that the wording could be improved, but I think that the recommendation is generally appropriate.
> This text, from section 3.6?
> 
>   1) Loop detection cannot be performed on the RTP level.  When
>      carelessly connecting two misconfigured MCUs, a loop could be
>      generated.
> 
>   2) There is no information about active media senders available in
>      the RTP packet.  As this information is missing, receivers cannot
>      use it.  It also deprives the client of information related to
>      currently active senders in a machine-usable way, thus preventing
>      clients from indicating currently active speakers in user
>      interfaces, etc.
> 
>   Note that deployed MCUs (and endpoints) rely on signalling layer
>   mechanisms for the identification of the contributing sources, for
>   example, a SIP conferencing package [RFC4575].  This alleviates, to
>   some extent, the aforementioned issues resulting from ignoring RTP's
>   CSRC mechanism.

And in RFC 5117 section 3.5, which says:

   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.

   To avoid the aforementioned issues, the MCU needs to implement two
   features.  First, it needs to act as a Mixer (see Section 3.4) and
   forward the selected media stream under its own SSRC and with the
   appropriate CSRC values.  Second, the MCU needs to modify the RTCP
   RRs it forwards between the domains.  As a result, it is RECOMMENDED
   that one implement a centralized video switching conference using a
   Mixer according to RFC 3550, instead of the shortcut implementation
   described here.


> I have my opinions about these issues (I've mentioned them to you in another message).
> There are scenarios where these issues are not problems. And no protocol violation is identified in this text.
> 
> I agree that the video-switching-MCU scenario described in RFC 5117 section 3.5 has problems, because it chooses to neither be one nor the other; I have no problems with recommending against that. It's RFC 5117 section 3.6 that is the one I think engineers should be free to use when they think the engineering tradeoffs are appropriate.

I agree that there are scenarios where these issues are not problematic, but there are also cases where they are. We believe the RFC 3550 mixer and translator models are better, and not more complex to implement or signal, which is why our draft recommends them. 

>>> - In the list of other extensions, section 6.2, you say that two extensions are "not recommended" - is this a recommendation against (like NOT RECOMMENDED would be), or simply a declaration that their use or non-use is of no concern?
>> My feeling is there's no clear benefit for RTCWeb from implementing these other extensions. The wording is perhaps a little strong, and could be weakened.
> I don't have an opinion, and would be happy to see "not recommended" interpreted as "RTCWEB doesn't care whether you use them or not". A recommendation against them would need a justification.

Sure.

>>> - there are some sections with garbled grammar (the last paragraph of section 7.2, before 7.2.1, is particularly irksome to the eye), but I assume that this will be reviewed in later versions; the meaning comes through.
>> 
>> Yeah, I'll review it and try to improve things in a coming version.
>> 
> Thanks!


-- 
Colin Perkins
http://csperkins.org/