[MMUSIC] Mod to draft-ietf-mmusic-rfc2326bis-40

Christian Groves <Christian.Groves@nteczone.com> Wed, 14 January 2015 02:10 UTC

Return-Path: <Christian.Groves@nteczone.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 7405A1ACE0F for <mmusic@ietfa.amsl.com>; Tue, 13 Jan 2015 18:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2qn7IZsFfAzT for <mmusic@ietfa.amsl.com>; Tue, 13 Jan 2015 18:10:11 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CA51ACE6C for <mmusic@ietf.org>; Tue, 13 Jan 2015 18:10:09 -0800 (PST)
Received: from ppp118-209-52-98.lns20.mel4.internode.on.net ([118.209.52.98]:56005 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <Christian.Groves@nteczone.com>) id 1YBDPG-00034n-1M; Wed, 14 Jan 2015 13:10:02 +1100
Message-ID: <54B5CFFC.7000904@nteczone.com>
Date: Wed, 14 Jan 2015 13:10:04 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: mmusic mailing list <mmusic@ietf.org>, Roni Even <ron.even.tlv@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/BiWCc755UxZSTpeqPSAHfEJUTUE>
Subject: [MMUSIC] Mod to draft-ietf-mmusic-rfc2326bis-40
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: <http://www.ietf.org/mail-archive/web/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: Wed, 14 Jan 2015 02:10:13 -0000

Hello,

draft-ietf-mmusic-rfc2326bis-40 
<https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/> has 
been in state MISSREF for some time now. See below:

2014-02-11    draft-ietf-mmusic-rfc2326bis-40.txt [C214]
MISSREF*R(1G)
REF    draft-ietf-avtcore-rtp-circuit-breakers    NOT-RECEIVED
     draft-ietf-mmusic-rtsp-nat    IN-QUEUE
H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed.
"Real Time Streaming Protocol 2.0 (RTSP)"
Bytes: 764018
Working Group: Multiparty Multimedia Session Control

There is still a dependency on draft-ietf-avtcore-rtp-circuit breakers 
which is holding up an RFC number being assigned. My understanding is 
that it could be quite awhile before the circuit breakers draft is approved.

There's only one reference to the circuit breakers draft in C.1.6.3 
"Bit-rate adaption", i.e.
    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].

I wondering if it would be possible to change this slightly so that the 
circuit breakers draft becomes informative whilst still keeping the 
congestion control requirement as a MUST? i.e.
"... all implementations using a non-congestion controlled unicast 
transport protocol, like UDP, MUST implement multimedia congestion 
control. For example: by utilising the mechanism defined by "Multimedia 
Congestion Control: Circuit Breakers for Unicast RTP Sessions 
[I-D.ietf-avtcore-rtp-circuit-breakers]."

This would mean that RTSP2.0 could finally become an RFC.

Would this be possible?

Regards,
Christian