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

[Colin Perkins <[e-mail]>]

Hi Zahed,

On 11 Nov 2014, at 21: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-
>   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

This looks good, although you might say “it is RECOMMENDED that” here?

Colin





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



-- 
Colin Perkins
https://csperkins.org/