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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 26 January 2015 16:15 UTC

Return-Path: <magnus.westerlund@ericsson.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 49CD31A8AA5 for <mmusic@ietfa.amsl.com>; Mon, 26 Jan 2015 08:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 XNFSf3RD1QRi for <mmusic@ietfa.amsl.com>; Mon, 26 Jan 2015 08:15:57 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1673A1A8A15 for <mmusic@ietf.org>; Mon, 26 Jan 2015 08:15:50 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-9d-54c668355124
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F7.D7.24955.53866C45; Mon, 26 Jan 2015 17:15:49 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.195.1; Mon, 26 Jan 2015 17:15:48 +0100
Message-ID: <54C66834.3090401@ericsson.com>
Date: Mon, 26 Jan 2015 17:15:48 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, Christian Groves <Christian.Groves@nteczone.com>, mmusic mailing list <mmusic@ietf.org>, Roni Even <ron.even.tlv@gmail.com>
References: <54B5CFFC.7000904@nteczone.com> <786615F3A85DF44AA2A76164A71FE1AC38394F@FR711WXCHMBA03.zeu.alcatel-lucent.com> <54BEC96A.4090504@cisco.com>
In-Reply-To: <54BEC96A.4090504@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvja5pxrEQgxuvJSz+tP5itPjyvpHF 4v0FXYupyx+zWPxtZ3Zg9Wh9tpfVY8rvjaweO2fdZfdYsuQnk8eK8zNZAlijuGxSUnMyy1KL 9O0SuDKWbPnEVDBTqWLj9XtsDYwdMl2MnBwSAiYSc1/3M0HYYhIX7q1nA7GFBI4wSly8bAZh L2eU6DnrBWLzCmhLvFh8FKyeRUBV4tWt/YwgNpuAhcTNH41gvaICwRKLnz9lhagXlDg58wlL FyMXh4jAF0aJpT+fgzUIC9hIvH06lQliwXRGiQNrpEBsTgFNiXm7v4LFmQUMJI4smsMKYctL NG+dzQxRry3R0NTBOoFRYBaSHbOQtMxC0rKAkXkVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmA4H9zyW3UH4+U3jocYBTgYlXh4N649GiLEmlhWXJl7iFGag0VJnNfO+FCIkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsZWGbE3ezveO+9tUgzLOXkhN66mnUlI4/M0FfXcWJE9bFqrQyq2 HZJmXrxBwnf+m5d3trDWuptxt+vw73KXvtl1r3DTkxePnJ9G/enROiueunFroV7Sl3u1R243 +881i3OWi+HLDo23dlHQyNq56r/rosXHEtJNfvUmfH0bba1ydLrulZjwcCWW4oxEQy3mouJE ABc1vu9IAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/7_uNzniwpGcOrcJdYOrMJOZGn3c>
Subject: Re: [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: Mon, 26 Jan 2015 16:15:59 -0000

Hi,

Unfortunately I don't see an easy way to address this issue.

So the reference to the circuit breakers draft is clearly normative as
it specifies a minimal behaviour for avoiding persistent congestion from
RTP based media controlled by RTSP. So reclassifying it to informative,
basically would remove the requirement on having such a mechanism. Which
in my view is not acceptable.

I do wonder if one can get the RFC-editor to release the RFC number
ahead of time? I think it might be worth asking nicely from the chairs.
After all the document is in the queue. There is only one document
missing and that is at least a WG document. And one that is needed by
multiple WGs. Thus, it will happen.

Or isn't that sufficient for you Christian?

Cheers

Magnus

On 2015-01-20 22:32, Flemming Andreasen wrote:
> We'll probably need to hear from Magnus as well (since he's the main
> author). I'm not sure if he is back from leave yet or not.
> 
> Thanks
> 
> -- Flemming
> 
> On 1/14/15 3:55 AM, Schwarz, Albrecht (Albrecht) wrote:
>> No objections from my side because the requirement as such is still
>> sufficiently covered.
>> Thus, would support that change proposal.
>> -Albrecht
>>
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian
>> Groves
>> Sent: Mittwoch, 14. Januar 2015 03:10
>> To: mmusic mailing list; Roni Even
>> Subject: [MMUSIC] Mod to draft-ietf-mmusic-rfc2326bis-40
>>
>> 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
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------