Subject: [rmcat] I-D Action: draft-ietf-rmcat-nada-02.txt

From: [email-masked]
Date: Fri, 18 Mar 2016 09:45:07 -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 of the IETF.

        Title           : NADA: A Unified Congestion Control Scheme for Real-Time Media 
        Authors         : Xiaoqing Zhu
                          Rong Pan
                          Michael A. Ramalho
                          Sergio Mena de la Cruz
                          Paul E. Jones
                          Jiantao Fu
                          Stefano D'Aronco
                          Charles Ganzhorn
	Filename        : draft-ietf-rmcat-nada-02.txt
	Pages           : 25
	Date            : 2016-03-18

Abstract:
   This document describes NADA (network-assisted dynamic adaptation), a
   novel congestion control scheme for interactive real-time media
   applications, such as video conferencing.  In the proposed scheme,
   the sender regulates its sending rate based on either implicit or
   explicit congestion signaling, in a unified approach.  The scheme can
   benefit from explicit congestion notification (ECN) markings from
   network nodes.  It also maintains consistent sender behavior in the
   absence of such markings, by reacting to queuing delays and packet
   losses instead.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rmcat-nada-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-nada-02

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: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Fri, 18 Mar 2016 16:50:27 +0000

Hi, 

This is an updated version of the NADA draft.  The main changes are as follows: 

* Added a section on feedback requirement (Sec. 5.3)
* Incorporated previous review comments from Stefan; 
* Incorporated previous review comments from Zahed; 
* Updated the section on "Implementation Status" to include a pointer to wireless test case results; 
* Corrected errata listed at the end of http://www.ietf.org/proceedings/94/slides/slides-94-rmcat-7.pdf; 

Thanks,
Xiaoqing 

________________________________________
From: rmcat <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Friday, March 18, 2016 11:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: [rmcat] I-D Action: draft-ietf-rmcat-nada-02.txt

Abstract:

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 21 Mar 2016 08:31:28 +0000

Hi Xiaoqing

Glanced through your updated draft. 
I have some comments on the adjustment to competing flows, which is my main
concern right now (regardless of algorithm)

Quote : "   In order for a delay-based flow to hold its ground when
competing
   against loss-based flows (e.g., loss-based TCP), it is important to
   distinguish between different levels of observed queuing delay.  For
   instance, a moderate queuing delay value below 100ms is likely self-
   inflicted or induced by other delay-based flows, whereas a high
   queuing delay value of several hundreds of milliseconds may indicate
   the presence of a loss-based flow that does not refrain from
   increased delay.

   When packet losses are observed, the estimated queuing delay follows
   a non-linear warping inspired by the delay-adaptive congestion window
   backoff policy in [Budzisz-TON11]: "

I have fiddled quite a bit with various approaches in order to reach to
point where SCReAM can work well in the presence of competing loss based TCP
flows and still have something that does not exacerbate self-inflicted
congestion in LTE scenarios. Quite recently I had to redo this part of the
algorithm (section 4.1.2.2. in the SCReAM draft will need a slight update).
The reason is that I  switched to model the Linux TCP stack and that is a
slight bit more aggressive in its behavior than the one I used previously.
Once the SCReAM algo is tuned to work well for the competing flows test
cases, the challenge is to avoid that the target queuing delay is increased
when the LTE test cases are run. This is quite a challenge !, queuing delay
spikes above 100ms are not uncommon, they can occur in handover or when a
new user with heavy traffic enters the cell. I believe now that I have
something that is the best current compromise between the wireless testcases
and the LTE test cases, i.e. it can handle competing TCP flows (test cases
5.6 and 5.7) and still avoids self-inflicted congestion in LTE, but as with
all compromises it is obvious that one would do better if one test set is
ignored.

The " When packet losses are observed..." statement raises questions. Does
this mean that it is enough with one single packet loss or does the packet
loss rate need to exceed a given threshold in order for the warping to take
effect. 

I have some experience with trying to use detected packet losses as an
indicator to switch to a more aggressive (less delay sensitive) mode. What I
have seen is that the RMCAT flow quite often miss to see the packet losses,
this comes quite natural if the TCP flow grabs a large portion of the
bottleneck. This has of course forced SCReAM to drop the bitrate even more,
with an even lower probability that it will see a packet loss. I guess the
AQM (or tail drop?) selection  and/or the burstiness of the TCP flows play a
role here, combined with the fact that the RMCAT flows are more paced by
nature.

/Ingemar

> -----Original Message-----
> From: Xiaoqing Zhu (xiaoqzhu) [mailto:[email-masked]]
> Sent: den 18 mars 2016 17:50
> To: [email-masked]
> Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-nada-02.txt
> 
> Hi,
> 
> * Corrected errata listed at the end of
> http://www.ietf.org/proceedings/94/slides/slides-94-rmcat-7.pdf;
> 
> Thanks,
> Xiaoqing
> 
> 
> From: rmcat <[email-masked]> on behalf of internet-
> [email-masked] <[email-masked]>
>         Title           : NADA: A Unified Congestion Control Scheme for
Real-Time
> Media