[MMUSIC] 1 week notice: Downgrading RTSP 2.0 reference to RTP circuit breaker

Flemming Andreasen <fandreas@cisco.com> Fri, 25 September 2015 00:40 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E491B4361 for <mmusic@ietfa.amsl.com>; Thu, 24 Sep 2015 17:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye1Wn-f6JDlK for <mmusic@ietfa.amsl.com>; Thu, 24 Sep 2015 17:40:50 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B661B4363 for <mmusic@ietf.org>; Thu, 24 Sep 2015 17:40:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3056; q=dns/txt; s=iport; t=1443141644; x=1444351244; h=from:subject:to:cc:message-id:date:mime-version: content-transfer-encoding; bh=WmfLQI/ACFyJ2e/dAprWacXbqFg0X4WSUn00nqI8MKg=; b=SdFkanLrdgFBmX1+ccGZkIKkAdxXiYWU3ZF77k4eV7jnM5T2eHJSsWSS BhnIK9h+vm+l1auZbslfUhLj3JXegOrRJySy+KeXWbThm6opiHCbgvk5s dCidN5DOLam5b/6/MmK8YrCv3LOA8yb4QEq/yZV+fz8LaaHvaQmzBW/dA I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQAgCClwRW/5tdJa1dgySEZ7oZAQ2Hc4FJOBQBAQEBAQEBgQqEJycPAQU4CAE1AgUWCwILAwIBAgFLDQgBAYgqt2qUKAEBAQEBAQQBAQEBHoEihVGKCoJwgUMBBJVniliCM4FPFYQhgn6SJx8BAUKEHSKKHwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,583,1437436800"; d="scan'208";a="30006422"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 25 Sep 2015 00:40:43 +0000
Received: from [10.155.84.186] (dhcp-10-155-84-186.cisco.com [10.155.84.186]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8P0ehuj021303; Fri, 25 Sep 2015 00:40:43 GMT
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org>
Message-ID: <5604980C.2080808@cisco.com>
Date: Thu, 24 Sep 2015 20:40:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/dvIpnp-jxYF0tPom7MMGV1cdYCM>
Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" <draft-ietf-mmusic-rfc2326bis@tools.ietf.org>
Subject: [MMUSIC] 1 week notice: Downgrading RTSP 2.0 reference to RTP circuit breaker
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2015 00:40:51 -0000

Greetings MMUSIC

As you may know, draft-ietf-mmusic-rfc2326bis-40 is currently in the RFC 
Editor's queue. It has been sitting there for 589 (!) days due to a 
normative reference to draft-avtcore-rtp-circuit-breakers. The ITU-T has 
a dependency on RTSP 2.0 which has prevented prevented them from 
publishing one of their specifications for a year and a half at this 
point. The RTSP 2.0 authors, chairs and ADs (incl. Transport) have 
discussed this situation and are proposing to change the reference to 
draft-avtcore-rtp-circuit-breakers to being informative rather than 
normative.The plan is to change it back to normative after 
circuit-breakers gets published at some future point in time.

The resulting text changes are provided below as well.

If anybody has any objections to this, please let us know no later than 
Thursday, October 1, 2015.

Thanks

     Ari & Flemming (MMUSIC chairs)



—

Proposed change:

OLD
C.1.6.3.  Bit-rate adaption

    RTCP Receiver reports and any additional feedback from the client
    MUST be used to adapt the bit-rate used over the transport for all
    cases when RTP is sent over UDP.  An RTP sender without reserved
    resources MUST NOT use more than its fair share of the available
    resources.  This can be determined by comparing on short to medium
    term (some seconds) the used bit-rate and adapt it so that the RTP
    sender sends at a bit-rate comparable to what a TCP sender would
    achieve on average over the same path.

    To ensure that the implementation's adaptation mechanism has a well
    defined outer envelope, all implementations using a non-congestion
    controlled unicast transport protocol, like UDP, MUST implement
    Multimedia Congestion Control: Circuit Breakers for Unicast RTP
    Sessions [I-D.ietf-avtcore-rtp-circuit-breakers].

NEW
C.1.6.3.  Bit-rate adaptation

   RTCP Receiver reports and any additional feedback from the client
   MUST be used to adapt the bit-rate used over the transport for all
   cases when RTP is sent over UDP.  An RTP sender without reserved
   resources MUST NOT use more than its fair share of the available
   resources.  This can be determined by comparing on short to medium
   term (some seconds) the used bit-rate and adapt it so that the RTP
   sender sends at a bit-rate comparable to what a TCP sender would
   achieve on average over the same path.

   To ensure that the implementation's adaptation mechanism has a well
   defined outer envelope, all implementations using a non-congestion
   controlled unicast transport protocol, like UDP, MUST implement
   congestion control.  A baseline safety against persistent congestion
   is "Multimedia Congestion Control: Circuit Breakers for Unicast RTP
   Sessions" [I-D.ietf-avtcore-rtp-circuit-breakers].  There is also
   ongoing work on standard specifications for RTP/RTCP congestion
   control in the IETF in the RMCAT WG.  Implementers are strongly
   encouraged adopt the latest usable work.