[rtcweb] #19: Section 7.2: Congestion Control Extensions
"rtcweb issue tracker" <trac+rtcweb@trac.tools.ietf.org> Sat, 20 April 2013 01:48 UTC
Return-Path: <trac+rtcweb@trac.tools.ietf.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 B8F0621F91BB for <rtcweb@ietfa.amsl.com>; Fri, 19 Apr 2013 18:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 tSd1QlvtuiRg for <rtcweb@ietfa.amsl.com>; Fri, 19 Apr 2013 18:48:18 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB121F91C4 for <rtcweb@ietf.org>; Fri, 19 Apr 2013 18:48:17 -0700 (PDT)
Received: from localhost ([127.0.0.1]:36810 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+rtcweb@trac.tools.ietf.org>) id 1UTMuR-0006kY-IH; Sat, 20 Apr 2013 03:48:11 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: rtcweb issue tracker <trac+rtcweb@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: rtcweb
Date: Sat, 20 Apr 2013 01:48:11 -0000
X-URL: http://tools.ietf.org/rtcweb/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/rtcweb/trac/ticket/19
Message-ID: <066.cafc635ba698c26a8adc82620078c6ab@trac.tools.ietf.org>
X-Trac-Ticket-ID: 19
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org
X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com
Resent-Message-Id: <20130420014818.0CFB121F91C4@ietfa.amsl.com>
Resent-Date: Fri, 19 Apr 2013 18:48:17 -0700
Resent-From: trac+rtcweb@trac.tools.ietf.org
Cc: rtcweb@ietf.org
Subject: [rtcweb] #19: Section 7.2: Congestion Control Extensions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 20 Apr 2013 01:48:18 -0000
#19: Section 7.2: Congestion Control Extensions 7.2. RTCP Extensions for Congestion Control As described in Section 5.1.6, the Temporary Maximum Media Stream Bit Rate (TMMBR) request is supported by WebRTC senders. This request can be used by a media receiver to impose limitations on the media sender based on the receiver's determined bit-rate limitations, to provide a limited means of congestion control. (tbd: What other RTP/RTCP extensions are needed?) As described in Section 5.1.6, the Temporary Maximum Media Stream Bit Rate (TMMBR) request is supported by WebRTC senders. This request can be used by a media receiver to impose limitations on the media sender based on the receiver's determined bit-rate limitations, to provide a limited means of congestion control. (tbd: What other RTP/RTCP extensions are needed?) With proprietary congestion control algorithms issues can arise when different algorithms and implementations interact in a communication session. If the different implementations have made different choices in regards to the type of adaptation, for example one sender based, and one receiver based, then one could end up in situation where one direction is dual controlled, when the other direction is not controlled. (tbd: How to ensure that both paths and sender and receiver based solutions can interact) [BA] Some nasty unresolved issues here. In particular, I am concerned about potential gaps in worldview between sender-side and receiver-side congestion control implementations. Is our goal here to guarantee that a sender-side implementation can interoperate with a receiver-side implementation? Or that a sender-side implementation has the information it needs? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: <https://tools.ietf.org/wg/rtcweb/trac/ticket/19> rtcweb <http://tools.ietf.org/rtcweb/>
- [rtcweb] #19: Section 7.2: Congestion Control Ext… rtcweb issue tracker
- Re: [rtcweb] #19: Section 7.2: Congestion Control… Colin Perkins
- Re: [rtcweb] #19: Section 7.2: Congestion Control… rtcweb issue tracker