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

[Zaheduzzaman Sarker <[e-mail]>]

Hi Varun,

Thanks. Please see inline below prefixed with [Zaheduzzaman Sarker].

BR

Zahed

From: Varun Singh [mailto:[e-mail]] 
Sent: den 11 november 2014 23:01
To: Zaheduzzaman Sarker
Cc: Karen E. E. Nielsen; Colin Perkins; Varun Singh; rmcat WG; Randell Jesup
Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt

Hi Zahed,
Look's good. A minor nit inline. 
On 11 Nov 2014 11:30, "Zaheduzzaman Sarker" <[e-mail]> wrote:
>
> 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-
AFAIK there are no other circuit breakers, I'd suggest removing such as.

[Zaheduzzaman Sarker] yes, there is only one such draft so far, are we sure that will be the last one? May be, but I was not sure hence used “such as”.
 
>    circuit-breakers], are required to protect the network from excessive
Excessive congestion --> congestion collapse?

[Zaheduzzaman Sarker] ok, but “excessive congestion” this was picked from the current circuit breaker draft ☺

>    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
> >
> > ==================================================
>