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

Harald Alvestrand <harald@alvestrand.no> Wed, 31 August 2011 07:39 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9721F8C53 for <rtcweb@ietfa.amsl.com>; Wed, 31 Aug 2011 00:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.999
X-Spam-Level:
X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=3.599, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG7Fj9+1Wp0H for <rtcweb@ietfa.amsl.com>; Wed, 31 Aug 2011 00:39:51 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7421F8C46 for <rtcweb@ietf.org>; Wed, 31 Aug 2011 00:39:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9562839E165; Wed, 31 Aug 2011 09:40:03 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkQb-r87IKqc; Wed, 31 Aug 2011 09:40:02 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E35E939E074; Wed, 31 Aug 2011 09:40:01 +0200 (CEST)
Message-ID: <4E5DE59D.6070102@alvestrand.no>
Date: Wed, 31 Aug 2011 09:41:17 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
References: <20110828175441.24054.11368.idtracker@ietfa.amsl.com> <57BFE815-5A39-4AC5-9787-80E13D34B68E@csperkins.org> <4E5B9513.6040606@alvestrand.no> <F40AE990-5CB6-4C5B-9F90-AAA98F0AEA2B@csperkins.org>
In-Reply-To: <F40AE990-5CB6-4C5B-9F90-AAA98F0AEA2B@csperkins.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review of draft-perkins-rtcweb-usage-03 (Re: Fwd: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2011 07:39:52 -0000

On 08/30/11 18:22, Colin Perkins wrote:
> Harald,
>
> 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.

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.
>> - 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.
Thanks for the reassurance!
>> - 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.

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