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

[Zaheduzzaman Sarker <[e-mail]>]

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

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.

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

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

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

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

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. 

	-# 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?

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
>