Joel, thank you for your review. Xiaoqing, thanks for updating the document. I entered a Yes ballot.
Best, Alissa > On Aug 25, 2019, at 9:34 AM, Joel M. Halpern <[email protected]> wrote: > > Thank you Xiaoqing. The revised documents looks good to me. > Yours, > Joel > > On 8/25/2019 12:33 AM, Xiaoqing Zhu (xiaoqzhu) wrote: >> 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" >> <[email protected] on behalf of [email protected]> 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" <[email protected]> >> 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. >> > >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
