Hi Joel, Just wanted to update that we've submitted the revised draft (-12) where changes as stated below for addressing your comments. https://tools.ietf.org/html/draft-ietf-rmcat-nada-12 Thanks again for reviewing this draft and helping to improve it. Best, Xiaoqing On 8/13/19, 10:31 AM, "rmcat on behalf of Joel M. Halpern" <rmcat-bounces@xxxxxxxx on behalf of jmh@xxxxxxxxxxxxxxx> wrote: Thank you. Those changes will address my concerns very effectively. Yours, Joel On 8/13/2019 11:26 AM, Xiaoqing Zhu (xiaoqzhu) wrote: > Dear Joel, > > Many thanks for your review of this draft. Please find our responses as below, tagged [Authors]. > > Best, > Xiaoqing (on behalf of all authors) > > On 8/5/19, 5:17 PM, "Joel Halpern via Datatracker" <noreply@xxxxxxxx> wrote: > > Reviewer: Joel Halpern > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-rmcat-nada-11 > Reviewer: Joel Halpern > Review Date: 2019-08-05 > IETF LC End Date: 2019-08-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is almost ready for publication as an Experimental RFC > > Major issues: > It is unclear reading this RFC how the observation information is to be > communicated from the receiver to the sender. At first I thought it was to > use the RTP Receiver report. But there is no description of how to map the > fields to that report. Then section 5.3 describes requirements for a > reporting mechanism, but does not seem to actually define one. Thus, I am > left unclear how independent interoperable implementations of this draft can > be created. > > [Authors] Thanks for raising this point. The feedback format is a topic covered > by another currently pending draft (https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-04), > which indeed aims at ensuring interoperability of independent implementations of > RMCAT congestion control solutions. Therefore, in this draft we only specified what type > of information is needed (e.g., receiving rate) and the unit and bit budget it is expressed > in (e.g., in bps in 32 bits) in the feedback from the receiver. We also pointed out in Sec. 6.4 > that an alternative way to implement this draft would be to leverage feedback messages > that contain per-packet information (e.g., delay and loss info) and to move all the calculations > from the receiver to the sender. > > [Author] Given the above considerations, we refrained from specifying a specific feedback > format. However, we should perhaps add a reference pointing to the cc-feedback-message draft. > Will do that in the next revision. > > Minor issues: > The document has 7 front page authors. The shepherd writeup does not > comment on this. The shepherd writeup seems quite sparse. II would have > expected some reference to the experimental behavior described in the draft. > > [Authors] Thanks for raising the concern about long list of front page authors. We got some > additional guidance from the AD and will make some adjustments accordingly. > > [Authors] As for comments on the experimental behavior: we have presented in recent IETF meetings > on several sets of real-world evaluations of one implementation of NADA. But, admittedly, the draft > is lagging behind in not yet adding pointers to those results. Your suggestion is a great one and we'll add > corresponding pointer (see links below) and related discussions in the next version. > > * https://datatracker.ietf.org/meeting/103/materials/slides-103-rmcat-nada-implementation-in-mozilla-browser-00 > * https://datatracker.ietf.org/meeting/105/materials/slides-105-rmcat-nada-update-02.pdf > > > This comment is just to confirm that I am reading the draft correctly. It > looks like when the observed delay cross the delay boundary, the reporting > system reports using a smaller delay than actually approved (slightly more > than 1/9th of observed delay when delay is 3*QTH). I presume this is > intentional, and that the various analysis pointed to evaluate the risks of > such false reporting? > > [Authors] Yes, your understanding is correct. The main motivation for this "delay warping" > In the presence of persistently high queuing delay *and* presence of loss is to help the flow to > sustain a more fair rate when competing against aggressive loss-based flows. Will follow your > advice and add some discussions on the potential risks involved in performing this "delay warping". > > Is it intentional in section 4.3 in the pseudo-code that the rate clipping > (to keep the rate between RMIN and RMAX) is only applied to the gradual > rate change, not to the accelerated rate change? The later code says that > the clipping is always applied, which is what I would expect. > > [Authors] Thanks to the catch. The clipping is always applied. Will fix the text accordingly. > > Nits/editorial comments: > > > [Authors] Thanks again for your above comments. Our next round of revision (version -12) will incorporate > changes as mentioned in our above response. >
