Re: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt

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

Hi Roland,

Thanks much for reading our draft and for providing your comments.  

Please see answers to your questions below inline, marked [XZ].  In general, these are very valuable comments/critiques, and we'll address them accordingly in the next revision for better clarity of the draft. 

Thanks!
Xiaoqing

________________________________________
From: Bless, Roland (TM) <[e-mail]>
Sent: Friday, October 27, 2017 10:04 AM
To: Xiaoqing Zhu (xiaoqzhu); [e-mail]
Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt

Hi,

I just read draft-ietf-rmcat-nada-05.txt for the first time and have
some (probably dumb) questions (mainly related to the delay-based part):
- The draft mentions a "15-tap minimum filter" (p. 12) and a
  "15-tab minimum filter" (p. 16). One of the seems to contain
  a type. Moreover, I have no clue what that actually is.
  Is it simply a minimum filter over the last 15 measured
  values?

[XZ]  Thanks for catching the typo.  They were meant to be "15-tab minimum filter", meaning taking the minimum value of the previous 15 measured values.  I just realized that this is not a standard term, will re-word to "minimum filter with a window size of 15" in the next revision. 


- The description in 4.2 states:
      update baseline delay: d_base = min(d_base, d_fwd)
  is this where the minimum filter is applied? If so
  better use min_filtered(d_base, d_fwd) and define
  what that is.

[XZ]  Your understanding is correct.  Agree that your proposed description (explicitly calling out the filtering option) is more precise.  Will change accordingly.  

- 4.3 mentions "base delay expiration", but I wasn't able
  to find a discussion in section 5 about it.

[XZ] The mention of "base delay expiration" refers to the potential scenario where an earlier measured base delay value may no longer be valid, e.g., due to underlying route change, and therefore the need to maintain a limited history window for estimating base delay.  This has been discussed in other drafts on delay-based scheme such as LEDBAT (Sec. 5.2 of RFC 6817) and not specific to NADA.  I can add a brief discussion of this in Section 5 in the next revision.   

- 5.1.1: "All delay estimations are based on sender timestamps with
  higher granularity than RTP timestamps."

  I'm not sure. RTP timestamps depend on the sampling clock frequency
  and this can be quite high, e.g., 8kHz corresponds to 125µs, 90kHz
  to 11µs. System clock resolution can be in the range of microseconds
  and sometimes even nanoseconds. So more interesting would be to state
  what minimum resolution the sender timestamps should have.

[XZ]  Thanks for raising this point. Based on our experimentation experience, a timestamp accuracy on the order of 100µs. Agree that it will be more informative to state the recommended timer resolution (we haven't carried out sufficient experiments to state a minimum, will stick to what we know) in the draft. 

- 6.3 "that a feedback interval below 250ms will not break
  up the feedback control loop of NADA congestion control."

  This is not clear to me. Does a "feedback interval below 250ms"
  mean a smaller interval and thus more frequent feedback?
  "feedback below 250 ms" could also mean slower and less frequent
  feedback.
  If so, I don't understand why more frequent feedback would
  "break up the feedback control loop". An unambiguous
  statement would be better.


[XZ]  Apologies for the confusion.  By "feedback interval below 250ms" we mean feedback intervals smaller than 250ms, i.e., more frequent feedback.  The word "interval" is kind of crucial here, but probably not sufficiently robust.  I can revise it (e.g., by adding an equivalent term on "more frequent interval") in the next version to avoid such potential ambiguity.  


Regards,
 Roland