Re: [rmcat] Review of draft-ietf-rmcat-nada-01

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hi Zahed, 

Thanks for reviewing the draft and providing your input. Most of your
comments are related to clarifying the expressions in the draft, which I
really like.  They can be addresses with relatively local edits.

More detailed responses inline below (also for my own reference when
revising the draft later).

Best,
Xiaoqing



On 12/3/15, 6:17 AM, "rmcat on behalf of Zaheduzzaman Sarker"
<[e-mail] on behalf of [e-mail]>
wrote:

>Hi,
>
>I have reviewed draft-ietf-rmcat-nada-01 :-) (my apologies for being so
>late).
>
>Overall the document looks good to me, I like the structure of it.
>However, below are my comments on some points that I think needs a bit
>clarification-
>
>1. Section 3.
>	a. Figure 1 : I believe the RTCP feedback should also via Network
>Node(s).


[XZ]  Ture. Except that the return path may encounter different
bottlenecks than along the forward path. Let me think about how to redraw
the diagram without making it too messy.

>	
>	b. First bullet : I don’t think a media encoder encodes source media
>stream into a RTP stream. It encodes raw frames into encoder frames which
>is later packetized into RTP packet.


[XZ] Agree. That’s a more accurate way to describe it.

>	
>	c. 2nd bullet : " The RTP sender also provides an RTP timestamp for each
>outgoing packet ", just to clarify is this the same RTP timestamp as
>defined in https://tools.ietf.org/html/rfc3550#section-5.1 , right?
>Asking because, later in section 4.2 there is a t_sent, which is defined
>as sending timestamp. Hence, the RTP timestamp and t_sent might be
>different.


[XZ]  Good point about the potential difference between RTP sampling
timestamp and sending timestamp. Ideally we want t_sent to align with the
sending time, not necessarily the RTP timestamp.  May need to introduce an
additional “internal” header to address this.

>
>2. Section 4.1 : the t_curr just says current timestamp, I believe some
>text indicating whether this is the system timestamp or the RTP time
>stamp will be nice.

[XZ]  Same need for clarification as before.


>
>3. Section 4.3: NADA clips the r_n within the range of [RMIN, RMAX] and
>it expects to know the value of RMIN and RMAX as allowed by encoder, so I
>imagined a Codec to CC interface here . However, in the
>https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-01#sect
>ion-5.1.1 the only mandatory interaction is CC to Codec. I don’t think
>this is an issue with NADA, it just needs some alignment with the codec
>interaction doc. I also think this also should be aligned in other CC
>algorithms documents.


[XZ]  Good suggestion. Will refer to the API doc and explain what to do if
that info is not provided by the codec.


>
>4. Section 5.1.1 : 15-tab should be 15-tap, right? Also a reference will
>be nice.

[XZ] typo to be corrected.

>
>5. Section 5.1.2 :   “It is assumed that ECN marking information at the
>IP header can be passed to the transport layer by the receiving
>endpoint.”  I believe there is slight doubts here on whether RTP is an
>application layer protocol or a transport layer protocol ☺. I would
>suggest something like this “It is assumed that ECN marking information
>at the IP header can be passed to the layer(s) by the receiving endpoint
>where the marking information can be accessed by the congestion control
>algorithms.”  

[XZ] Good point.  As I remember there is also some related discussion on
ECN in RTP (RFC6679) on avtcore mailing list. Will look that up to see if
there’s anything the NADA draft needs to be aware of.

>
>6. Section 6.1 : adding a definition “zero queuing delay” or ref to that
>will be nice.

[XZ]  Will do. 

>
>What I am missing is
>
>	-# discussion on how this algorithm is different from other proposed
>delay/packetloss based adaptation when it is operating on implicit
>congestion indications. It would be nice to give the reader and
>implementer an idea about the fundamental difference between NADA and for
>example - GCC. If the evaluation results shows both of the delay based
>algorithm performs similar, what would make one implementer select
>between NADA and GCC. As far as I see both of them reacting on varying
>packet queueing delay, is the main difference the use of different
>filtering or is there more? One thing is obvious that NADA aggregates the
>implicit and explicit congestion signals to fine tune reactions. AS GCC
>designers are planning to ditch their current packetloss based adaptation
>and may be come up with more advanced one, will that be very different
>from NADA? I am just asking the authors to shed some lights on the
>uniqueness of NADA. This will be also a comment towards GCC authors.


[XZ] Good point and suggestion. Except that I will not try to contrast it
agains one existing scheme, but will try to point out the unique features
of NADA (ensured stability for RTTs below a bound, support for weighted
fairness, unified behavior in the presence of loss/delay/marking etc.) I
agree that a reader will also want to know why this solution instead of
other delay/lossed-based schemes. I believe the requirement draft should
have covered the need for a new proposal already?

> 
>
>	-# the description of determining "rmode". The receiver is supposed to
>send "rmode" to the sender but I haven’t find any discussion (in section
>4.2 and section 5.1) on how the receiver determines the mode. Where did I
>missed it?

[XZ] Descriptions for determining “rmode” is towards the end of Sec. 4.2:
“… The criteria for operating in accelerated ramp-up mode are:…”. Let me
know if you find it clear enough.



>
>BR
>
>Zahed  
>
>> -----Original Message-----
>> From: Mirja Kühlewind [mailto:[e-mail]]
>> Sent: den 15 oktober 2015 15:07
>> To: Stefan Holmer; [e-mail]; Zaheduzzaman Sarker
>> Cc: rmcat WG ([e-mail]); Karen E. E. Nielsen
>> Subject: Review of draft-ietf-rmcat-nada-01
>> 
>> Hi Stefan, hi Zahed, hi Anurag,
>> 
>> you’ve agree at the last meeting to review the next version of
>>draft-ietf-rmcat-
>> nada. As there is a new version out now, it would be great if you could
>>review it
>> before the next meeting.
>> 
>> I’m cc’ing the group mailing list: Of course, if others are interested
>>in this work,
>> please also review now and send comments on the list or be prepared to
>> provide feedback at the next session directly to the authors!
>> 
>> Thanks in advance!
>> Karen & Mirja
>> 
>