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

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Sep 2015 20:40:44 -0400

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.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Sep 2015 08:16:09 -0400

> circuit-breakers gets published at some future point in time.

I am very fine with this. The effectiveness of RTP circuit breakers has
not been demonstrated in practice and they cause a number of
interoperability issues with current RTP implementations.

Simon