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

Colin Perkins <csp@csperkins.org> Tue, 30 August 2011 16:21 UTC

Return-Path: <csp@csperkins.org>
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 3E28A21F8C4F for <rtcweb@ietfa.amsl.com>; Tue, 30 Aug 2011 09:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 v9CpnLUy18+u for <rtcweb@ietfa.amsl.com>; Tue, 30 Aug 2011 09:21:27 -0700 (PDT)
Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5996721F8C22 for <rtcweb@ietf.org>; Tue, 30 Aug 2011 09:21:27 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QyR5S-0003Nv-n0; Tue, 30 Aug 2011 16:22:54 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <4E5B9513.6040606@alvestrand.no>
Date: Tue, 30 Aug 2011 17:22:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F40AE990-5CB6-4C5B-9F90-AAA98F0AEA2B@csperkins.org>
References: <20110828175441.24054.11368.idtracker@ietfa.amsl.com> <57BFE815-5A39-4AC5-9787-80E13D34B68E@csperkins.org> <4E5B9513.6040606@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1084)
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: Tue, 30 Aug 2011 16:21:28 -0000

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. 

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