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

From: Christian Groves <[email-masked]>
Date: Wed, 14 Jan 2015 13:10:04 +1100

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 14 Jan 2015 08:55:04 +0000

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:[email-masked]] 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:

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.

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]."

Would this be possible?

Regards,
Christian

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 Jan 2015 16:32:26 -0500

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:
> .

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jan 2015 17:15:48 +0100

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:
>> 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.
>> 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]."
>>

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Christian Groves <[email-masked]>
Date: Wed, 28 Jan 2015 21:28:11 +1100

Hello Magnus,

Yes unfortunately it doesn't seem to be an easy fix. I'd be happy if the 
RFC number was released ahead of time. However my understanding that 
this wasn't done any more (not that I would complain if they did release 
one).

Regards, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 28 Jan 2015 07:32:17 -0500

I'm not a big fan of short-circuiting the process and provide a stable 
reference to something that could change (nothing is final until it has 
been published). I do understand the special circumstances here though 
and we don't seem to be close to resolving the missing reference issue. 
In liue of that and the fact that 2326bis has been in progress for well 
over 10 years, I have asked the RFC Editor if we can have an RFC number 
assigned. Irrespective of whether they agree, I want to stress that this 
should be viewed as a clearly exceptional case and we don't want to set 
a precedent with it.

Thanks

-- Flemming (MMUSIC co-chair)

On 1/28/15 5:28 AM, Christian Groves wrote:
> Hello Magnus,
>
> Yes unfortunately it doesn't seem to be an easy fix. I'd be happy if 
> the RFC number was released ahead of time. However my understanding 
> that this wasn't done any more (not that I would complain if they did 
> release one).
>
> Regards, Christian
>