Subject: [rtcweb] Fwd: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 28 Aug 2011 18:59:50 +0100

Begin forwarded message:
> From: [email-masked]
> Date: 28 August 2011 18:54:41 GMT+01:00
> Subject: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt
> 
> A new version of I-D, draft-perkins-rtcweb-rtp-usage-03.txt has been successfully submitted by Colin Perkins and posted to the IETF repository.
> 
> Filename:	 draft-perkins-rtcweb-rtp-usage
> Revision:	 03
> Title:		 RTP Requirements for RTC-Web
> Creation date:	 2011-08-28
> WG ID:		 Individual Submission
> Number of pages: 22

This version makes the following changes relative to the -02 draft:

- Removed discussion of multiplexing for RTP sessions entirely, pending submission of a proposal for multiplexing audio and video within an RTP session (as discussed at IETF 81).

- Added a reference to draft-ietf-avtcore-srtp-vbr-audio-03 in Security Considerations.

- Added a recommendation that draft-ietf-avtcore-srtp-encrypted-header-ext-00 be used when the client-to-mixer and mixer-to-client audio level indication RTP header extensions are in use in SRTP encrypted sessions.

- Added Slice Loss Indication and Reference Picture Selection Indication messages as OPTIONAL loss tolerance mechanisms.

Comments and feedback are welcome.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 29 Aug 2011 15:33:07 +0200

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.

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.

- In section 3, you make the point that improper signalling of bandwidth 
can cause failure to interoperate (because of differing RTCP timings). 
Is there a (possibly theoretical) problem with interoperation between 
RTP/AVP and RTP/AVPF too, or have we verified that the AVPF profile 
always sends enough RTCP packets that AVP-conformant endpoints don't 
time out?

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

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

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 30 Aug 2011 17:22:42 +0100

Harald,

On 29 Aug 2011, at 14:33, Harald Alvestrand wrote:
> 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. 

> - In section 3, you make the point that improper signalling of bandwidth can cause failure to interoperate (because of differing RTCP timings). Is there a (possibly theoretical) problem with interoperation between RTP/AVP and RTP/AVPF too, or have we verified that the AVPF profile always sends enough RTCP packets that AVP-conformant endpoints don't time out?

I'm not aware of any problems here. They were designed to interoperate.

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

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

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

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

---

From: Randell Jesup <[email-masked]>
Date: Tue, 30 Aug 2011 13:31:36 -0400

> I'm not aware of any problems here. They were designed to interoperate.

Agreed, this should be fine and has been done a lot.

>> 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 so…
Or they're handling a usecase that isn't covered by the protocol or wasn't anticipated.
That may not be something "wrong" with the protocol - they may be using the wrong
protocol, or they may need a new protocol, or they may need an extension to the protocol
to cover this new usecase.

If it's a "covered" usecase, then there's something wrong with the protocol.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 31 Aug 2011 09:41:17 +0200

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

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.
> I'm not aware of any problems here. They were designed to interoperate.
Thanks for the reassurance!
> 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.

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.
> 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.
> Yeah, I'll review it and try to improve things in a coming version.
Thanks!

---

From: Colin Perkins <[email-masked]>
Date: Wed, 31 Aug 2011 21:48:06 +0100

On 31 Aug 2011, at 08:41, Harald Alvestrand wrote:
> 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 supporting both shared and split RTP sessions for multi-unicast

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.

...
>   some extent, the aforementioned issues resulting from ignoring RTP's

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. 

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

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