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

From: [email-masked]
Date: Mon, 27 Oct 2014 11:27:04 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF.

        Title           : Congestion Control Requirements for Interactive Real-Time Media
        Authors         : Randell Jesup
                          Zaheduzzaman Sarker
	Filename        : draft-ietf-rmcat-cc-requirements-07.txt
	Pages           : 11
	Date            : 2014-10-27

Abstract:
   Congestion control is needed for all data transported across the
   Internet, in order to promote fair usage and prevent congestion
   collapse.  The requirements for interactive, point-to-point real-time
   multimedia, which needs low-delay, semi-reliable data delivery, are
   different from the requirements for bulk transfer like FTP or bursty
   transfers like Web pages.  Due to an increasing amount of RTP-based
   real-time media traffic on the Internet (e.g. with the introduction
   of the Web Real-Time Communication (WebRTC)), it is especially
   important to ensure that this kind of traffic is congestion
   controlled.

   This document describes a set of requirements that can be used to
   evaluate other congestion control mechanisms in order to figure out
   their fitness for this purpose, and in particular to provide a set of
   possible requirements for real-time media congestion avoidance
   technique.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 29 Oct 2014 17:34:39 +0100

Hi Zahed, Randell,

As an individual I have made a quick read of version 07.
I am generally very happy with the updates. Still I have a few comments
which you make take into consideration:

General Comments on the substance:

#1:

As stated in
http://www.ietf.org/mail-archive/web/rmcat/current/msg00969.html, but also
by others previously, I think that the
text on the relation to the circuit breaker, right now placed in the
draft-ietf-rmcat-app-interaction-0,  should be lifted into this req doc.
Possibly in the following form:

RTP Circuit Breakers: The intent behind RTP circuit breakers
[I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill
switch of last resort, not true congestion control. The breakers should
never trip when an effective congestion control is operating.
An RMCAT congestion control algorithm should ensure that one
never approaches a situations which may trigger the breakers.

#2:

In respect to Fred Bakers comment on having an explicit requirement on the
algorithm to minimize self-induced latency, then
while I agree that an algorithm that fulfills the requirements in the
document need to support this requirement, then perhaps
it might still be beneficial to extend the sub clause 1.B. to more
explicitly address this issue also - e.g. - say (?)

It should provide this as-low-as-possible-delay transit even
            when faced with intermediate bottlenecks and competing
            flows.   Competing flows may limit what's possible to
            achieve. Special care must be taken for that the algorithm
minimizes
            self-induced latency.

Some detailed (mainly editorial) comments:

1.C:

Suggest to replace:

  It is expected that the mechanism reacts to
            the routing change events in a way that avoids delay
            buildup.

with:

 It is expected that the mechanism reacts to the effect of
            the routing changes in a way that avoids delay
            buildup.

There are no explicit events I presume (?)

1.D:

Is it correct to assume that what is meant more explicit here is:

It is assumed that a local or remote interface change can generate
            an explicit notification to the algorithm.

and if so, would it be relevant to clarify the text accordingly ?

1G.

Note that this competing
            traffic may on a shared access link,

may --> may exist ?

Section 3:

2nd paragraph:

TFRC's only consideration of loss
   events as congestion indication can be considered as biggest lacking
   looking at the current Internet deployment.

--> (?)

Looking at the current Internet deployment, looking at the current
Internet deployment TFRC's consideration of only loss

   events as congestion indication, can be considered as the biggest
lack of the algorithm.
   TFRC's only consideration of loss

   Looking at the current Internet deployment, TFRC's consideration for only

   loss events as congestion indication can be considered as biggest lacking

3rd paragraph:

variance --> variant

BR, Karen

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 30 Oct 2014 12:07:23 +0100

On 2014-10-29 17:34, Karen Elisabeth Egede Nielsen wrote:
> http://www.ietf.org/mail-archive/web/rmcat/current/msg00969.html, but
> also by others previously, I think that the
AN RMCAT congestion control will control a subset of flows that will be 
available in the network and the congestion may not only be caused by 
the RTP flows. In my understanding the media timeout and RTCP timeout 
circuit breaker can still trip no matter how effective congestion 
control is operating. Among the circuit breaker triggers those two 
usually means something went really wrong in the communication path like 
link failure, severe congestion by other flows.
> never approaches a situations which may trigger the breakers.
  Do you mean an RMCAT congestion will work as a circuit breaker as well 
and the requirements also includes that a RMCAT congestion algorithm 
should also be able to influence other traffics on the path as well? I 
guess not.

It is our expectation that any RTP application which supposed to 
generate huge amount of traffic must implement circuit breaker but in 
reality that may not be the case. An application which does not 
implement circuit breaker can use a RMCAT congestion control solution 
and vice versa.

To me the important thing  is "An RMCAT congestion control algorithm 
should be able to effectively functional in the presence or absence of 
RTP circuit breaker". It is "expected to operate within the constraints 
defined by these circuit breakers (as written in the circuit breaker 
draft, it is and "expected" behavior)" when circuit breaker is present 
and  that it should not cause congestion collapse when circuit breaker 
is not implemented.

>
>
> #2:
>
> In respect to Fred Bakers comment on having an explicit requirement on
> the algorithm to minimize self-induced latency, then
>              achieve. Special care must be taken for that the algorithm minimizes
>              self-induced latency.
>
>
Sounds good to me.
> Some detailed (mainly editorial) comments:
All your editorials looks great. thanks.

BR
-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER

Ericsson AB
Services, Media and Network Features
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
[email-masked]
www.ericsson.com

==================================================

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 30 Oct 2014 14:34:17 +0100

Hi Zahed,

>> also by others previously, I think that the text on the relation to
>> the circuit breaker, right now placed in the
>> [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch of
>> last resort, not true congestion control. The breakers should never
>> trip when an effective congestion control is operating.
>available in the network and the congestion may not only be caused by the
>RTP flows. In my understanding the media timeout and RTCP timeout circuit
>breaker can still trip no matter how effective congestion control is
>operating.
>Among the circuit breaker triggers those two usually means something went
>really wrong in the communication path like link failure, severe congestion
>by
>other flows.
>> An RMCAT congestion control algorithm should ensure that one never
>> approaches a situations which may trigger the breakers.
> and
>the requirements also includes that a RMCAT congestion algorithm should
>also
>be able to influence other traffics on the path as well? I guess not.

Agree.
>
>It is our expectation that any RTP application which supposed to generate
>huge amount of traffic must implement circuit breaker but in reality that
>may
>not be the case. An application which does not implement circuit breaker
>can
>use a RMCAT congestion control solution and vice versa.
>
>To me the important thing  is "An RMCAT congestion control algorithm should
>be able to effectively functional in the presence or absence of RTP circuit
>breaker". It is "expected to operate within the constraints defined by
>these
>circuit breakers (as written in the circuit breaker draft, it is and
>"expected"
>behavior)" when circuit breaker is present and  that it should not cause
>congestion collapse when circuit breaker is not implemented.
>

Would it then not be relevant to add this last paragraph (slightly
reformulated) to the requirement doc ?

BR, Karen

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 30 Oct 2014 14:45:07 +0100

> reformulated) to the requirement doc ?

Are you suggesting to add it as a new requirement? or as a general 
discussion (perhaps in the intro).

BR

Zahed

Ericsson AB

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 30 Oct 2014 15:05:29 +0100

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 ?

BR, Karen

AN RMCAT congestion control will control a subset of flows that will be
available in the network and the congestion may not only be caused by the
RTP flows. In my understanding the media timeout and RTCP timeout circuit
breaker can still trip no matter how effective congestion control is
operating. Among the circuit breaker triggers those two usually means
something went really wrong in the communication path like link failure,
severe congestion by other flows.
> approaches a situations which may trigger the breakers.
  Do you mean an RMCAT congestion will work as a circuit breaker as well and
the requirements also includes r the statements from the app interaction
stated in the following way:

But I

>-----Original Message-----
>From: Zaheduzzaman Sarker [mailto:[email-masked]]
>Sent: 30. oktober 2014 14:45
>To: Karen Elisabeth Egede Nielsen; Randell Jesup; Randell Jesup
>Cc: rmcat WG
>Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt
>
>
>
>>> should be able to effectively functional in the presence or absence
>>> of RTP circuit breaker". It is "expected to operate within the
>>> constraints defined by these circuit breakers (as written in the
>>> circuit breaker draft, it is and "expected"
>>> behavior)" when circuit breaker is present and  that it should not
>>> cause congestion collapse when circuit breaker is not implemented.
>>>
>>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 30 Oct 2014 16:38:31 +0100

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

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.

BR
-- 

Zahed

Ericsson AB