Subject: [rmcat] FW: New Version Notification for draft-zhu-rmcat-nada-05.txt

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Tue, 24 Mar 2015 17:04:24 +0000

Hi,

Please find below the updated draft on NADA.  The main updates are
summarized
as follows: 

* Description of the congestion control algorithm now inline with what we
last presented at IETF-91 in Honolulu:
- Non-linear warping of delay at receiver (Sec 5.3)
- Accelerated ramp-up at sender (Sec 6.1.1)

* More detailed descriptions and discussions on receiver behavior:
- Delay estimation and denoising: (Sec 5.1)
- Loss/marking ratio estimation: (Sec 5.2)
- Receiving rate estimation: (Sec 5.5)
- Choice of feedback interval: (Sec 5.6)

*  Re-ordered subsections in Sec 6 on sender behavior so that it flows in
the same order as how the sending/video rates are calculated

* Updated Sec 8 on implementation status

* Minor editorial updates throughout the text: fixing typos, etc.

Your comments and input are much appreciated.

Best,
Xiaoqing

On 3/24/15, 11:57 AM, "[email-masked]"
<[email-masked]> wrote:

>
>A new version of I-D, draft-zhu-rmcat-nada-05.txt
>has been successfully submitted by Xiaoqing Zhu and posted to the
>IETF repository.
>
>Name:		draft-zhu-rmcat-nada
>Revision:	05
>Title:		NADA: A Unified Congestion Control Scheme for Real-Time Media
>Document date:	2015-03-23
>Group:		Individual Submission
>Pages:		19
>URL:            
>http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-05.txt
>Status:         https://datatracker.ietf.org/doc/draft-zhu-rmcat-nada/
>Htmlized:       http://tools.ietf.org/html/draft-zhu-rmcat-nada-05
>Diff:           http://www.ietf.org/rfcdiff?url2=draft-zhu-rmcat-nada-05
>
>Abstract:
>   Network-Assisted Dynamic Adaptation (NADA) is a novel congestion
>   control scheme for interactive real-time media applications, such as
>   video conferencing. In NADA, the sender regulates its sending rate
>   based on either implicit or explicit congestion signaling in a
>   consistent manner. As one example of explicit signaling, NADA can
>   benefit from explicit congestion notification (ECN) markings from
>   network nodes. It also maintains consistent sender behavior in the
>   absence of explicit signaling by reacting to queuing delay and packet
>   loss.
>
>   This document describes the overall system architecture for NADA,
>   recommended behavior at the sender and the receiver, as well as
>   expected network node operations.
>
>                  
>        
>Needed to adjust the meta data so that all co-authors show up correctly.
>
>Thanks,
>Xiaoqing
>
>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.
>
>The IETF Secretariat
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 24 Mar 2015 17:00:56 -0500

Hi Xiaoqing,

I enjoyed reading the draft in the plane coming here, but unfortunately I
had brought the wrong draft (04),
(but then it was the wrong plane also - LH strike).

Anyway - could you enlighten me as an individual, and as chair, what the
purpose of the aqm descriptions of section 4 is.

Do you have this section to put the Nada solution into perspective (in
which case I suppose that it eventually should go away or be substantially
shortened)  - ? or is it there because Nada  has some dependencies to
"only" these kind of aqm mechanisms being in operation in the nodes (which
is then problematic for other reasons) ? or does this reflect the aqm
mechanisms used in the evaluations (in which case it should perhaps go
into the appendix, until it could go into the evaluations drafts) - or ,
finally, does this rather belong into the test cases or the tests
evaluations document ?

Many thanks ! :-)

BR, Karen

>-----Original Message-----
>From: rmcat [mailto:[email-masked]] On Behalf Of Xiaoqing Zhu
>(xiaoqzhu)
>Sent: Tuesday, March 24, 2015 12:04 PM
>To: [email-masked]
>Subject: [rmcat] FW: New Version Notification for draft-zhu-rmcat-nada-
>05.txt
>
>Hi,
>
>summarized as follows:
last
>presented at IETF-91 in Honolulu:
the
>same order as how the sending/video rates are calculated
>
>>A new version of I-D, draft-zhu-rmcat-nada-05.txt has been successfully
>>submitted by Xiaoqing Zhu and posted to the IETF repository.
>>
>>Title:		NADA: A Unified Congestion Control Scheme for
Real-Time
>Media
>>submission until the htmlized version and diff are available at
>>tools.ietf.org.
>>
>>The IETF Secretariat
>>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 25 Mar 2015 03:17:03 +0000

Karen, 

Thanks much for providing your feedback to the draft. My apologies again
for 
the glitches in delaying submission of the updated version. In any case,
changes
from version -04 to -5 are fairly local, so feel free to check them out at
a 
time of your convenience.  More comments are always welcome.

Regarding your question: to clarify NADA does *not* rely on any specific
AQM
operations at the network node. In fact one of our design goals is to make
it work with drop tail queues. But then we also want NADA to be able to
take
advantage of modern AQM schemes and perform better in their presence. The
intension of Section 4, therefore, is to provide some concrete examples of
network node operations we have tested NADA over (well, an earlier version
of
the algorithm, as documented in our PacketVideo¹13 workshop paper).  In
other
words its purpose was to provide some perspective.

Although in RMCAT the charter explicitly excludes definition of AQMs (for
all 
good reasons and I fully agree with), we still think that a viable
congestion
control solution should be able to work with various AQM schemes in the
network
since the endpoint may not have control over, or knowledge about, what
queuing
schemes are employed along the network path.

With your comment, I realize that given the charter of RMCAT explicitly it
may
make more sense to shorten that section or move that description to
appendix
or the test case draft (we do have a place holder section in the test case
draft). 
This may be one point worthy of discussion at the upcoming WG meeting on
Thursday. 

Best,
Xiaoqing