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