Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

To address the comments regarding adding text related to rtp circuit breaker, I am going to add following text ("-->" marks the beginning of the additional text) to the already existing text in the introduction of the draft. Let me know if it captures the essences of the discussions.

"One particular protocol portfolio being developed for this use case
   is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending
   multiple flows using the Real-time Transport Protocol (RTP) [RFC3550]
   between two peers, in conjunction with data flows, all at the same
   time, without having special arrangements with the intervening
   service providers. --> As RTP does not provide any congestion control
   mechanism; a set of circuit breakers, such as [I-D.ietf-avtcore-rtp-
   circuit-breakers], are required to protect the network from excessive
   congestion caused by the non-congestion controlled flows.  When the
   real-time interactive media is congestion controlled, it is
   recommended that the congestion control mechanism operates within the
   constraints defined by these circuit breakers when circuit breaker is
   present and that it should not cause congestion collapse when circuit
   breaker is not implemented.<--"

BR

Zahed

> -----Original Message-----
> From: rmcat [mailto:[e-mail]] On Behalf Of Zaheduzzaman
> Sarker
> Sent: den 3 november 2014 09:42
> To: Colin Perkins
> Cc: Karen E. E. Nielsen; Randell Jesup; rmcat WG
> Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt
> 
> 
> 
> On 2014-11-01 19:43, Colin Perkins wrote:
> > On 30 Oct 2014, at 15:38, Zaheduzzaman Sarker
> <[e-mail]> wrote:
> >> On 2014-10-30 15:05, Karen Elisabeth Egede Nielsen wrote:
> >>> Interworking with circuit breaker and prevention of collapse when circuit
> breaker is not active to me sounds like requirements.
> >>>
> >>> The same may goes for the statement from the app interaction
> reformulated, e.g.,  in the following way:
> >>>
> >>> The RMCAT congestion control should constrain the traffic under its control
> so that the circuit breaker only may trip as a consequence of issues exterior to
> the RMCAT congestion control, like link path failures or severe congestion
> caused by traffic flows not under RMCAT congestion control.
> >>>
> >>> My personal preference would be to have this become an explicit new
> requirement (with subclauses). Would you rather like to see this be discussed in
> the introduction only ?
> >>>
> >>
> >> If we define requirements on the relationship between circuit breaker and
> RMCAT congestion control algorithm then I think we will have to state more
> than what is stated above (explaining how the requirement can be realize when
> RTP/AVPF is used).
> >>
> >> The circuit breaker draft states -
> >> "Receiving rapid feedback about congestion events potentially allows
> >>    congestion control algorithms to be more responsive, and to better
> >>    adapt the media transmission to the limitations of the network.  It
> >>    is expected that many RTP congestion control algorithms will adopt
> >>    the RTP/AVPF profile for this reason, defining new transport layer
> >>    feedback reports that suit their requirements.  Since these reports
> >>    are not yet defined, and likely very specific to the details of the
> >>    congestion control algorithm chosen, they cannot be used as part of
> >>    the generic RTP circuit breaker.".
> >>
> >> This is a general wisdom that RMCAT congestion control algorithms with use
> RTP/AVPF. Correct me if I am wrong but we are yet to see the impact of circuit
> breaker when used with RTP/AVPF.
> >
> > The RTP circuit breaker draft does have some discussion of how it interacts
> with RTP/AVPF feedback, but I agree that we haven't fully explored how it
> interacts with reduced RTCP reporting intervals. That's the remaining open issue
> with the -07 version of the circuit breaker draft.
> >
> >> I was thinking that we can keep the relationship between the generic circuit
> breaker and congestion control algorithm as "expected" not as "required". Then
> we have eval guideline which can outline how to evaluate to candidate RMCAT
> Algorithms when circuit breaker is available and not available.
> >
> > Perhaps RECOMMENDED rather than REQUIRED?
> 
> yes, that sounds good to me.
> 
> BR
> 
> --
> 
> Zahed
> 
> ==================================================
> ANM ZAHEDUZZAMAN SARKER
> 
> 
> Ericsson AB
> Services, Media and Network Features
> Laboratoriegränd 11
> 97128 Luleå, Sweden
> Phone [phone]
> Fax [phone]
> SMS/MMS [phone]
> [e-mail]
> www.ericsson.com
> 
> ==================================================